JDK 24 是自 JDK 21 以來的第三個非長期支援版本。甲骨文公司 Java 平臺組首席架構師 Mark Reinhold 宣佈，JDK 24 已進入首個候選釋出階段。2024 年 12 月初，主線原始碼倉庫分支到 JDK 穩定版本倉庫（Rampdown 第一階段），這確定了 JDK 24 的功能集。對於關鍵漏洞，比如迴歸問題或嚴重的功能缺陷，可能會進行修復，但必須透過修復請求流程獲得批准。按照發布計劃，JDK 24 將於 2025 年 3 月 18 日正式釋出 。以 JEP（Java 增強提案）形式呈現的最終 24 項新特性，可分為五大類：核心 Java 庫、Java 語言規範、安全庫、HotSpot 和 Java 工具。

JEP 495：簡單原始檔和例項主方法（第四次預覽），在經過前三輪預覽後，此次釋出第四次預覽且內容無變化（僅第二次更改了名稱）。此前三輪預覽分別是：JDK 23 中的 JEP 477“隱式宣告類和例項主方法（第三次預覽）”；JDK 22 中的 JEP 463“隱式宣告類和例項主方法（第二次預覽）”；JDK 21 中的 JEP 445“匿名類和例項主方法（預覽）”。該特性旨在“改進 Java 語言，讓初學者編寫第一個程式時，無需理解為大型程式設計的語言特性”。這一 JEP 提案推進了甲骨文公司 Java 語言架構師 Brian Goetz2022 年 9 月發表的部落格文章《 Paving the on-ramp》。甲骨文公司技術人員諮詢成員 Gavin Bierman 已釋出規範文件初稿，供 Java 社群稽核。更多關於 JEP 445 的詳細資訊，可檢視[InfoQ 新聞報道](https://www.infoq.com/news/2025/02/java-24-so-far/)。

JEP 487：作用域值（第四次預覽），原名為“擴充套件本地變數（孵化）”。經過一輪孵化和三輪預覽後，此次推出第四次預覽且有一處變動。此前的預覽版本分別是：JDK 23 中的 JEP 481“作用域值（第三次預覽）”；JDK 22 中的 JEP 464“作用域值（第二次預覽）”；JDK 21 中的 JEP 446“作用域值（預覽）”；JDK 20 中的 JEP 429“作用域值（孵化）”。該特性支援線上程內部和執行緒之間共享不可變資料，與執行緒區域性變數相比更具優勢，尤其在使用大量虛擬執行緒時。與上一版預覽相比，唯一的變動是從`ScopedValue`類中移除了`callWhere()`和`runWhere()`方法，以使 API 更加流暢。透過`ScopedValue.Carrier`類中定義的`call()`和`run()`方法，可實現使用一個或多個繫結的作用域值的功能。

在完成評審後，JEP 489：向量 API（第九次孵化）根據前八輪孵化的反饋意見進行了改進。此前的孵化版本分別是：JDK 23 中的 JEP 469“向量 API（第八次孵化）”；JDK 22 中的 JEP 460“向量 API（第七次孵化）”；JDK 21 中的 JEP 448“向量 API（第六次孵化）”；JDK 20 中的 JEP 438“向量 API（第五次孵化）”；JDK 19 中的 JEP 426“向量 API（第四次孵化）”；JDK 18 中的 JEP 417“向量 API（第三次孵化）”；JDK 17 中的 JEP 414“向量 API（第二次孵化）”；JDK 16 中作為孵化模組釋出的 JEP 338“向量 API（孵化）”。原本計劃複用最初的孵化狀態進行重新孵化，最終決定繼續按順序編號。向量 API 將持續處於孵化階段，直到 Valhalla 專案 的必要特性作為預覽特性推出。屆時，向量 API 團隊將對向量 API 及其實現進行調整以使用這些特性，並將向量 API 從孵化階段推進到預覽階段。

JEP 483 提前類載入和連結旨在“透過讓應用程式的類在 HotSpot Java 虛擬機器啟動時，以載入和連結狀態即時可用，從而縮短啟動時間”。這可以透過在一次執行過程中監控應用程式，並將所有類的載入和連結形式儲存在快取中，以供後續執行使用來實現。該特性將為未來縮短啟動時間和預熱時間奠定基礎。

JEP 497 基於模組格的抗量子數字簽名演算法旨在“透過提供符合 FIPS 204 標準的基於模組格的抗量子數字簽名演算法（ML-DSA）實現，增強 Java 應用程式的安全性”。這將透過實現 Java 的`KeyPairGenerator`、`Signature`和`KeyFactory`類來達成。

受 Lilliput 專案 啟發，JEP 450 緊湊物件頭（實驗性）提議“在 64 位架構下，將 HotSpot JVM 中物件頭的大小從 96 到 128 位縮減至 64 位”。由於該特性被視為實驗性的，預設處於停用狀態，若開發者啟用可能會導致意外後果。更多關於 JEP 450 的詳細資訊，可檢視 InfoQ 新聞報道(https://www.infoq.com/news/2025/02/java-24-so-far/)。

JEP 404 分代 Shenandoah（實驗性）提議提供一種實驗性的分代模式，同時不影響非分代的 Shenandoah 垃圾回收器，目標是在未來的 JDK 版本中將分代模式設為預設選項。該 JEP 最初計劃用於 JDK 21，但由於“評審過程中發現的風險，以及對如此大量程式碼貢獻進行全面評審的時間不足”，最終從 JDK 21 的最終特性集中移除。當時，Shenandoah 團隊決定將目標設定為未來的 JDK 版本，以“儘可能提供最佳的分代 Shenandoah”。#### JDK 25

JDK 25 計劃於 2025 年 9 月釋出正式版，目前尚無針對 JDK 25 的 JEP 提案。不過，基於一些 JEP 候選提案和草案，尤其是已提交的那些，我們可以推測哪些 JEP 有可能被納入 JDK 25。甲骨文公司技術人員諮詢成員 Gavin Bierman 在給 Java 社群的一封郵件中宣佈，他計劃在 2025 年 9 月 JDK 25 釋出時，敲定 JEP 495“簡單原始檔和例項主方法（第四次預覽）”中所謂的“入門匝道（on-ramp）”特性。截至目前，相關草案尚未建立，但預計很快會有變動。

JEP 502“穩定值（預覽）”，原名為“計算常量（預覽）”，引入了計算常量的概念，即最多初始化一次的不可變值持有者。它兼具`final`欄位的效能和安全優勢，同時在初始化時機上更具靈活性。

JEP 草案 8340343“結構化併發（第五次預覽）”提議進行第五次預覽，對 API 做出幾處修改，以從前四輪預覽中獲取更多反饋。此前的預覽版本分別是：即將在 JDK 24 正式版中釋出的 JEP 499“結構化併發（第四次預覽）”；JDK 23 中的 JEP 480“結構化併發（第三次預覽）”；JDK 22 中的 JEP 462“結構化併發（第二次預覽）”；JDK 21 中的 JEP 453“結構化併發（預覽）”。該特性引入結構化併發，將“在不同執行緒中執行的相關任務組視為單個工作單元，從而簡化錯誤處理和取消操作，提高可靠性並增強可觀測性”，進而簡化併發程式設計。其中一項 API 修改提議是，透過靜態工廠方法而非公共建構函式來開啟`StructuredTaskScope`介面。

JEP 草案 8326035“CDS 物件流”提議在 Z 垃圾回收器（ZGC）中為類資料共享（CDS）新增物件歸檔機制，並採用統一的 CDS 物件歸檔格式和載入器。該特性將把 GC 的實現細節和策略與 CDS 歸檔物件流機制分開。

JEP 草案 8300911“PEM API（預覽）”引入了一種簡單直觀的 API，用於對隱私增強郵件（PEM）格式進行編碼和解碼，描述最多可更改一次的值持有者。PEM 格式將用於儲存和傳送加密金鑰及證書。

JEP 草案 8291976“在 HttpClient 中支援 HTTP/3” 提議更新 JDK 11 中釋出的 JEP 321“HTTP 客戶端”，以支援 HTTP/3 協議。這將使應用程式和庫能夠與 HTTP/3 伺服器互動，並透過最少的程式碼更改獲得 HTTP/3 帶來的優勢。我們預計甲骨文公司很快就會確定針對 JDK 25 的 JEP。

Michael Redlich，在過去 25 年裡，Michael Redlich 始終是 Java 社群的活躍成員。2001 年，他創立了花園州 Java 使用者組（前身為 ACGNJ Java 使用者組），這個使用者組至今仍在持續運營。

從 2016 年開始，Mike（Michael 的暱稱）擔任 InfoQ 的 Java 社群新聞編輯。在此期間，他每月撰寫新聞報道，進行技術內容創作，還參與技術評審工作，為社群貢獻頗豐。他曾在諸多重要場合發表演講，比如甲骨文 Code One 大會、企業新興技術大會、Trenton 計算機節（TCF）、TCF IT 專業人員大會，以及眾多 Java 使用者組活動。

在技術規範制定領域，Mike 是 Jakarta NoSQL 和 Jakarta Data 規範的貢獻者，積極推動相關技術的發展。同時，他還參與了 Jakarta EE 大使領導委員會，為該技術生態的發展出謀劃策。2023 年 4 月，他榮獲 Java Champion 稱號，這無疑是對他在 Java 領域卓越貢獻的高度認可。

Mike 在新澤西州克林頓市的埃克森美孚技術與工程公司工作了長達 33 年半之久，最近剛剛退休。在那裡，他積累了豐富的科學實驗室和網路應用程式定製化開發經驗。此前，他還在 Ai-Logix 公司（現 AudioCodes）擔任技術支援工程師，不僅為客戶提供專業的技術支援，還負責開發電話應用程式。