OpenJDK 8 至少會支援到 2023 年

At Red Hat, we intend to provide support for OpenJDK 8 to our customers until 2023, and our policy of always “upstream first” implies that OpenJDK 8 will continue to be updated for critical bugs and security fixes until then.

看來才剛開始，只有1-n。在這種情境下要寫n-m 感覺有點麻煩。

AuthorRef 這個想法有趣。不過大多數的 relation 都不是 aggregates ，這不是變成 8 成以上的 relation 都要多加一個 *Ref class 嗎?

還好，有點貴

沒有這種支援才麻煩說

金融業也很多用 oracle db 吧

這麼說也是，不過台灣金融業都要 IBM，所以應該就直接跟 IBM 買支援了？

如果這樣賺翻的話表示會顧更多專職開發者? 應該會是好事？（然後其實是更多律師跟業務XD

金融業才不管什麼划不划算的咧…

會嗎？以現在 Oracle 的計費方式，我猜很多公司會考慮 Azul 這種有上限的比較划算，或者本來有買 RedHat Linux 的公司就用 RedHat 上的 Java 了 XD

這個模式再 run 個三年就知道了。

結果… 是 Oracle 賺翻了

另外架 DB 去改 OS 參數是很常見的事，裝過 Oracle DB 就會知道。

寫程式十多年都沒有聽 DBA 提起過有這回事 ...

可能是我和 DBA 比較不熟吧 XD

P.S. 一般開發時用的 DB (測試區) 都是用預設值 ...

一般而言都不用動到，postgresql 舊版的預設參數都很保守，現在好多了。

另外架 DB 去改 OS 參數是很常見的事，裝過 Oracle DB 就會知道。

沒想到架個 DB 也需要改到 Kernel Parameters ...

不過應該是 PostgreSQL 有丟出相關錯誤訊息時才需要改吧？

結論:

But if you just want the "standard", currently my best advice is to use the OpenJDK builds by Oracle, AdoptOpenJDK builds or the one in your Operating System (Linux).

大部分的內部 AP 系統開發, 如果已經走 microservice 架構, 應該比較少機會用那麼多的 RAM吧.

自從外包給 RDS 後現在都沒機會動到這些設定了

之前elasticsearch有建議heap不要開太大 有這個應該就不一樣了

ZGC restricts itself to 4Tb heaps which require 42-bits, leaving 22-bits of possible state of which it currently uses 4-bits: finalizable, remap, mark0 and mark1.

喔喔，4TB 耶！

不過可能也沒機會用到這麼多 ram ...

沒錯，除非你有付錢買 support，不然還是轉 OpenJDK 吧…

總之要有一個觀念，Oracle JDK LTS 有跟沒有一樣，都是只到半年。

純 rest 要用名詞, 所以要改寫成 /user/{id}/approval。

我是有看到用動詞的例子：

• Best practices for RESTful web service design1：第 9 頁提到 Use nouns for non-resource actions，但是例子卻是給 convert, calculate (動詞)？
• RESTful 與 Rails2：這裡有提到 /bookmarks/:id/edit (edit 也是動詞)

要講究純 rest 到最後變得像是在考文法一樣, 咬文嚼字, 我個人是不太喜歡浪費時間在這種地方啦。

說的也是 ...

而且用 PATCH 就對了嗎？approve user 這個動作有可能改到三個 Table 以上，不一定是只改 user.approved 這個 boolean flag 而已啊。

我只是覺得 approve 這個動作應該只是在 update 資料，所以用 PATCH 比較合適 ...

不過改三個 Table 有可能代表了同時修改三個資源，這部份 REST 目前也沒有規範到 ...

就像您說的那樣，最後會是 REST 和 RPC 混用吧

純 rest 要用名詞, 所以要改寫成 /user/{id}/approval。

要講究純 rest 到最後變得像是在考文法一樣, 咬文嚼字, 我個人是不太喜歡浪費時間在這種地方啦。

而且用 PATCH 就對了嗎？approve user 這個動作有可能改到三個 Table 以上，不一定是只改 user.approved 這個 boolean flag 而已啊。

版號當然是要出現在 url.

出現在 header 就變成只能用 js call, 而且也不能 cache. 放 header 只是給自己製造麻煩而已

API 版號應該出現在 URI 中還是 HTTP header 中？以 REST API Versioning 的描述兩種皆可，但看完論文後哪種較好呢？

• 我覺得 API 版號應該出現在 URI 中，因為這樣可以保證 client 端不會 call 錯版本 ... (雖然這樣的 URI 有點不好看 ...)
• 若是用 parameter 或 header 來指定 API 版號，就有 client 端給錯資料而 call 錯版本的風險 (當然如果 client 端是可信賴的就沒差)

參考資料：Versioning RESTful Services1