If your application really does require maintenance windows due to some historical architectural issue, then you should treat this as a problem.

（猛點頭）

記得兩個實作上不太一樣，但都是靠犧牲 throughput

跟 ZGC 一樣在拼 1ms 以下。

ZGC 是用 CPU cycle 換來的 low pause 的，Shenandoah 也一樣嗎？

ZGC 還有一個特性是不管 heap 大小性能都一樣

Spring Boot 2.2 今年七月就 EOL 了，我猜應該不會再花時間測試是不是有支援 17 ...

但 Hibernate 連上一版 5.3 都有支援真的很用心 XD

我還在 spring boot 2.2 ，但是 2.x 應該不會全部回溯支援 17 吧，正常情形是這樣。所以 hibernate 做法真奇特。

spring 我一直卡著不升就是要等 17 LTS 一起升、一起測試。不然太累了

對啊，可能是因為 17 是 LTS 關係？ Spring 也有一直在測試 17 的相容性，預計下週釋出的 Spring Boot 2.5.5 就會正式支援了(但我們專案用 2.5.3 + Java 17 可以正常開起來沒問題)

5.x 版都支援 17 ? 這種做法真的很少見，通常只有最新版才有份

難得給 Hibernate 一個讚

Java 17 is 8.66% faster than Java 11 and 2.41% faster than Java 16 for G1GC (default).

Java 17 is 6.54% faster than Java 11 and 0.37% faster than Java 16 for ParallelGC.

The Parallel Garbage Collector is 16.39% faster than the G1 Garbage Collector.

有競爭是好事啊，現在才有這麼多版 OpenJDK 可以選

Java 11 已經支援到 2024 了，再延長的話就會跟 Java 8 一樣到 2026 了吧 XD

Oracle 你看看你

先是死要錢，Oracle JDK 通通收費，然後現在是各種社群、大公司的 OpenJDK distro 滿地開花。沒人要裝本家的 JDK，現在才要回頭搞免費授權？

太慢啦

而且誰不知道你過個幾年又會搞新的授權要錢，你家 JDK 永遠不會是首選了。

然後這個 Oracle JDK LTS 也只支援三年而已 (LTS 二年加延一年)，三年根本不夠好嗎！

BTW, 隨著 JDK 17 發佈，第二輪 OpenJDK distro 會面臨新的挑戰:

• JDK 11 的支援是否繼續延長？

JDK 8 和 11 會繼續 backport、繼續支援的 distro 最終會成為最多人使用的版本。

有蠻多 Java 17 相關的議程，而且 Oracle 很貼心的根據時區安排了兩天議程，有興趣的可以報名參加

已經在寫的會繼續寫，但之前沒跳船的現在大概不會考慮了。然後新的 framework/library 大概也不會以 kotlin 為賣點

只剩 android 在寫 kotlin?

繞了一圈又回到 Java，Kotlin 感覺又被放生

業界轉 kotlin 的風潮已經消退了，取而代之的是狂加功能的 Java 語言，這算是個正向刺激的好例子。不然 Java 以前死都不肯加新功能。

BTW，Spring 太成熟實在不曉得有什麼好改的，可能的話希望新版 reflection 用少一點吧，啟動速度快一點

完全不用 IDE 的開發者多半程式語言就那幾種，哪天他被要求寫 iOS/Android 就知道了，API 和 build 都複雜到爆炸。不過通常選擇不去寫就是了，直接離職，繼續維持 清白

只用 IDE 然後搞不懂 cli 在 build 什麼… 初學者 ok，但你做了三五年還停在這邊就很危險了。你通常是你單位裡最不重要、最容易被替換的開發者。

專業的開發人員兩者都會用，知道適用範圍和其限制，也了解內部運作的機制。最多是有偏好而已。

我現在還是會用一些 twitter snowflake 的變型 (kaif 本身就是)

有時序的 64bit unique id 好處實在很多，缺點大概就程式碼不夠正規，沒有類似概念的人會搞不懂你在幹嘛 (大家都是用 database auto-increment...)

還有另一個地雷就是 64bit id 放不下 json (js number 只有 53 bit)，要特別 encode 或是用字串處理 (程式又更難懂了一些)

如果用 128bit UUID 大概就沒以上的缺點，但傷的是資料庫

想用程式碼寫隻龍，從 第一隻概念驗證的龍1 到現在經過四年，終於長腳了…XD

這些日子以來的龍2

我們家是openJ9，正式環境記憶體都很小

剛剛發現 SDKMAN 可以下載 Temurin 了

 Temurin       |     | 16.0.2       | tem     |            | 16.0.2-tem          
               |     | 11.0.12      | tem     |            | 11.0.12-tem         
               |     | 8.0.302      | tem     |            | 8.0.302-tem         

好像是授權的關係... 但我們主要還是用 hotspot 版本

現在有了，可能是時間差 XD

JDK下載成功但只有hotspot版本，OPENJ9以後只能在IBM下載的樣子

他們的安裝頁面還是空的

怎麼沒有 zgc 的 cpu 比較?

雖然 cassandra 的比較沒差, 但還是想知道 overhead

我也還有幾個 plugin 還沒支援...