Tag: jdk

Java 21 (LTS) 推出

Hacker News 上注意到 Java 21 的消息：「JDK 21 Release Notes」、「Java 21 / JDK 21: General Availability」、「OpenJDK JDK 21 General-Availability Release」。

對於沒什麼在寫 Java 的人來說 (也是等於比較沒有在接觸 Java 圈子消息的人)，比較意外的是這是推出的是 LTS 版本，距離上次的 LTS (Java 17) 才兩年前 (2021/09/14)：

JDK 21 will be a long-term-support (LTS) release from most vendors, including Oracle. If you’re upgrading from the previous LTS release, JDK 17, then you have many more JEPs to look forward to, summarized here:

翻了一下 Java version history，可以知道同時支援的 LTS 版本變成四個了，而最近一次會終止的會是 Java 11，Red Hat 會在 2024/10 終止，而 Oracle 會在 2026/09 終止，這中間還會不會再增加 LTS...？

雖然沒什麼在寫，但還是常常會看到有人提到這次引入了 Virtual Threads 與 Generational ZGC，這應該是討論度最高的。

看了 Virtual Threads 的說明，有種「反璞歸真」的感覺...

在二十年前的時候，就已經有很多 userland threading library，讓應用程式可以用 threading design pattern 開發程式，而當時 x86 下的作業系統開始要遇到多 CPU 的環境，才開始在 kernel 裡支援 threading，讓應用程式裡面的 threading 可以打散到多個不同的 CPU 上面。

記得當年 FreeBSD 4 之後對 SMP 與 threading 的爭論導致分家出 DragonflyBSD，而 FreeBSD 的多 CPU 效能與穩定性要一直到 FreeBSD 7 才穩了下來。

現在 Java 反過來為了降低 OS thread 造成的 overhead，讓 java.lang.Thread 可以跑在 userland 裡面，不要用 kernel 提供的 OS thread...

另外又讓我想到 kqueue、epoll 以及 libevent 的事情了，不過這扯遠了...

提議 OpenJDK 的程式碼 UTF-8 化

在 Hacker News 上看到提議把 OpenJDK 的程式碼 UTF-8 化：「Make JDK source code UTF-8 (openjdk.org)」，原始的 jira ticket 在「Make JDK source code UTF-8」這邊。

主要是現在的 source code 沒有統一標準：

Currently, the source code in the JDK is in an ill-defined encoding. There is no official declaration of the encoding used. It is "mostly ASCII", but the relatively few non-ASCII characters used are not well-defined. In many cases, it is latin-1, but I am pretty certain other encodings are used for e.g. Asian translations.

而 mailing list 上看起來還是有想要維持 ASCII 的討論：「Making the source code utf-8」，不過他提出來的理由我覺得不太行，在 console 跑 vi 或是 emacs 我覺得不太是個好理由...

Java 17 (JDK 17)，新的 Java LTS 版本 (然後來看 GC)

Java 17 (JDK 17) 釋出，這是 Oracle 本家新的 LTS 版本，引用的是 jdk-dev 的 mailing list：「Java 17 / JDK 17: General Availability」。另外在 Hacker News 上的討論可以翻一下：「Java 17 / JDK 17: General Availability (java.net)」。

上一個 LTS 版本是 Java 11，所以很自然的也會有從 Java 11 之後的新功能說明：「JEPs in JDK 17 integrated since JDK 11」。

對於只是拿來用，而不是拿來開發的人來說，我的重點都放在 JVM 的 GC 效能以及特性。

從 Java 11 預設的 G1GC 來看，可以看到一些改善，從「JEP 345: NUMA-Aware Memory Allocation for G1」(Java 14) 這個看起來會改善 G1GC 在多實體 CPU 的情況下效能，不過看起來有 -XX:+UseNUMA 這個參數要加。

再來是「JEP 346: Promptly Return Unused Committed Memory from G1」(Java 12) 可以在閒閒的時候跑個 GC 把記憶體給 OS。

接下來是兩個新的 GC (相較於 11 版)，一個是 ZGC，另外一個是 Shenandoah，都沒有取代 G1GC，但兩個都有對應使用的場景。

ZGC 有列兩個 JEP：「JEP 376: ZGC: Concurrent Thread-Stack Processing」、「JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)」，目標是讓 GC pause time 盡可能的低，另外在 wiki 上面的說明則是有提到目標在 1ms 以下：

The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past.

Sub-millisecond max pause times

Shenandoah 列出了「JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)」，不過先前的「JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)」講的比較詳細，目標是希望 GC 不影響目前正在執行的程式：

Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

可以看出來兩個新的 GC 都是希望降低 pause time，對於 latency 敏感的應用應該都可以測試看看，可以預期整體的 throughput 會低一些。

回頭來看 G1GC，有人跑了 benchmark 測試了 Java 11 與 Java 17 的 G1GC 差異：「How much faster is Java 17?」。

可以看到 G1GC 的改善 (藍色的部份) 看起來還是不少，不過有些情況下是會變慢的。文章裡面還有提到 Parallel GC，這邊就不提了，可以自己看...

等各家 build 出來後來測看看 Cassandra 的效能影響如何...

各種 Java 的版本

看到這則 tweet，提到 Java 的支援度：

主要是裡面有張圖列出了目前市場上有的選擇，可以當關鍵字來查：

目前看起來如果要 Java 8 只有三個方案，其中有過 TCK 的只有兩個，看起來用 Amazon Corretto 算是個還不錯的選擇？

Elasticsearch 1.2.0

由於 Elasticsearch 的想法與實做比起 Solr 吸引人，可以看到愈來愈多團體換過去...

而前幾天 Elasticsearch 的官方放出 1.2.0 與 1.1.2 的消息：「elasticsearch 1.2.0 and 1.1.2 released」。

1.2.0 最大的改變是強制使用 Java 7 了，也就是不能在 Ubuntu 12.04 下安裝 default-jre 了，變成要裝 openjdk-7-jre。(要注意，官方建議的是 Oracle 官方的 JDK，而非 OpenJDK)

如果是 Ubuntu 14.04 就沒這個問題。(因為 default-jre 會裝 Java 7)

另外一個大改變是，之前產生安全問題的 dynamic scripting 預設關掉了，也就是 CVE-2014-3120。

目前我的進度只到看完 mapping，但還沒實際開始塞資料進去玩...