JDK 20 和 JDK 21 最新動态

作者 | Michael Redlich

譯者 | 劉雅夢

策劃 | 丁曉昀

JDK 20是自JDK 17,以來的第三個非長期支援（LTS）版本，正如甲骨文 Java 平台組的首席架構師Mark Reinhold所宣布的那樣，它已經進入了初始候選版本階段。主線源代碼庫已于 2022 年 12 月中旬（Rampdown 第一階段）分支到 JDK穩定代碼庫，并定義了 JDK 20 的特性集。嚴重錯誤，如回歸或嚴重的功能問題，可能會得到修複，但必須通過修複請求（Fix-Request）流程獲得準許。根據釋出時間表，JDK 20 将于 2023 年 3 月 21 日正式釋出。值得注意的是，JEP 438 已于 2023 年 3 月初被添加到了特性集中。

最終包含了 7 個 JEP 形式的新特性，它們可以被分為兩類：核心 Java 庫和 Java 規範。

這些新特性中的 5 個被歸類到了核心 Java 庫中：

• JEP 429：作用域值（孵化器）
• JEP 434：外部函數和記憶體API（第二次預覽）
• JEP 436：虛拟線程（第二次預覽）
• JEP 437：結構化并發（第二個孵化器）
• JEP 438: Vector API (第五個孵化器)

這些新特性中有 2 個被歸類到了 Java 規範中：

• JEP 432：記錄模式（第二次預覽）
• JEP 433：switch模式比對（第四次預覽）

我們研究了這些新特性以及支援它們的四個主要 Java 項目（Amber、Loom、Panama和Valhalla ），這些項目旨在孵化一系列元件，然後通過精心策劃的合并最終将其納入到 JDK 中。

Amber 項目

JEP 432，記錄模式（第二次預覽），為了響應上一輪預覽JEP 405，記錄模式（預覽版）的回報，它結合了增強功能。提議使用記錄模式來增強語言，以解構記錄值。記錄模式可以與類型模式結合使用，以“實作一種強大的、聲明式的、可組合的資料導航和處理形式”。類型模式最近通過 JDK 17 中提供的 JEP 406，switch模式比對（預覽版）和 JDK 18 中提供的 JEP 420，switch模式比對（第二次預覽）擴充到了 switch 語句标簽中。與 JEP 405 相比，變化包括：增加了對泛型記錄模式類型參數的推斷支援；增加了對記錄模式出現在增強 for 語句條件判斷中的支援；并删除對了對命名記錄模式的支援。

類似地，JEP 433：switch模式比對（第四次預覽），結合了增強功能以響應前三輪預覽的回報：JEP 427，switch模式比對（第三次預覽），在 JDK 19 中提供；JEP 420，switch模式比對（第二次預覽），在 JDK 18 中提供；以及 JEP 406，switch模式比對（預覽版），在 JDK 17 中提供。與 JEP 427 相比，變化包括：簡化了 switch 标簽文法；現在， switch 表達式和語句以及其他支援模式的構造體都支援泛型類型模式和記錄模式的類型參數推斷。

Loom 項目

JEP 429，作用域值（孵化器），一個正在孵化的 JEP，最初名為範圍局部變量（孵化器，Extent-Local Variables），提議線上程内部和線程之間共享不可變資料。這比線程局部變量更可取，尤其是在使用大量虛拟線程時。

JEP 436，虛拟線程（第二次預覽），提議基于 JDK 19 中所提供的 JEP 425，虛拟線程（預覽版）對該特性進行第二次預覽，以便留出時間來為該特性的演進提更多的回報和體驗。該特性為 Java 平台提供了虛拟線程，這是一種輕量級線程，可以極大地減少編寫、維護和觀察高吞吐量并發應用程式的工作量。需要注意的是，除了少量在 JDK19 中被被固化的 JEP 425 API 外，本預覽版本沒有進行任何更改，是以沒有在第二次預覽中提出。有關 JEP 425 的更多詳細資訊，請參閱 InfoQ 的新聞報道和甲骨文 Java 平台組 Java 開發人員倡導者José Paumard的 JEP Café螢幕截圖。

JEP 437，結構化并發（第二個孵化器），提議基于 JDK 19 中所提供的 JEP 428，結構化并發（孵化器）重新孵化，以便留出時間來為該特性的演進提更多的回報和體驗。此特性的目的是通過引入一個庫來将在不同線程中運作的多個任務視為單個工作單元，進而簡化多線程程式設計。這可以簡化錯誤處理和撤銷，提高可靠性，并增強可觀測性。唯一的變化是更新了 StructuredTaskScope 類，以支援在任務作用域中建立的線程可以繼承作用域的值。這簡化了線程間不可變資料的共享。有關 JEP 428 的更多詳細資訊，請參閱 InfoQ新聞報道。

Panama 項目

JEP 434，外部函數和記憶體API（第二次預覽），基于回報進行了改進，并基于 JDK 19 中所提供的 JEP 424，外部函數和記憶體API（預覽版）進行了第二次預覽。相關孵化包括 JEP 419，外部函數和記憶體API（第二個孵化器），在 JDK 18 中傳遞；以及 JEP 412，外部函數和記憶體API（孵化器），在 JDK 17 中傳遞。該特性為 Java 應用程式提供了一個 API，通過高效地調用外部函數和安全地通路不受 JVM 管理的外部記憶體，在 Java 運作時之外與代碼和資料進行互操作。JEP 424 的更新包括：統一了 MemorySegment 和 MemoryAddress 接口，即，記憶體位址由零長度的記憶體段模組化；并且增強了 MemoryLayout 密封接口，以便于與在 JDK 19 中提供的 JEP 427，switch中的模式比對（第三次預覽）一起使用。

JEP 438，Vector API(第五個孵化器)，結合了對前四輪孵化器回報進行了增強：JEP 426，Vector API（第四個孵化器），在 JDK 19 中傳遞；JEP 417，Vector API（第三個孵化器），在 JDK 18 中傳遞；JEP 414，Vector API（第二個孵化器），在 JDK 17 中傳遞；JEP 338，Vector API（孵化器），作為 JDK 16 中的孵化器子產品提供。該特性旨在增強 Vector API，以根據 JEP 424，外部函數和記憶體API（預覽版）的定義，從 MemorySegment 中加載并存儲向量。

JDK 21

計劃于 2023 年 9 月釋出一個 GA 和下一個 LTS 版本，目前JDK 21的 Proposed to Target 有兩（2）個 JEP。

JEP 430，字元串模闆（預覽版），一種 JEP 類型的特性，提議使用字元串模闆來增強 Java 程式設計語言，字元串模闆類似于字元串字面量，但包含在運作時合并到字元串模闆中的嵌入式表達式。該特性已被歸類為 JDK 21 的 Proposed to Target，但尚未正式公布審查日期。

JEP 431，序列集合，提議引入“一個組能新表示集合概念的接口，這些集合的元素按照定義良好的序列或順序排列，作為集合的結構屬性。”其動因是由于集合架構（Collections Framework）中缺乏定義良好的排序和統一操作集。該特性已被歸類為 JDK 21 的 Proposed to Target，但尚未正式公布審查日期。

我們可以根據一些 JEP 草案和候選版本來推測哪些額外的 JEP 有可能會被包含在 JDK21 中。

JEP 草案 8303358，作用域值（預覽版），由紅帽公司的傑出工程師Andrew Haley和Andrew Dinn送出，對即将釋出的 JDK 20 中所提供的 JEP 429，作用域值（孵化器）進行了改進。其最初名為範圍局部變量（孵化器，Extent-Local Variables），由Loom項目支援，該特性旨在實作線程内部和線程之間不可變資料的共享。這比線程局部變量更可取，尤其是在使用大量虛拟線程時。雖然這個草案還沒有達到 Candidate 狀态，但描述中明确指出，這個 JEP 将被添加到 JDK21 中。

JEP 草案 8277163，值對象（預覽版），是由 Valhalla 項目贊助的一個 JEP 特性，提議建立價值對象——無身份辨別的值類，指定其執行個體的行為。該草案與 JEP 401，原語類（預覽版）相關，目前仍處于 Candidate 狀态。

JEP 435，異步堆棧跟蹤VM API，一種 JEP 類型的特性，提議定義一個有效的 API，用于收集堆棧跟蹤資訊，以便根據包含 Java 和本地堆棧幀資訊的信号處理器進行分析。

JEP 401，原語類（預覽版），在 Valhalla 項目的支援下，引入了開發人員聲明的原語類——特殊類型的值類——如前面提到的值對象（預覽版）JEP Draft 中所定義——定義了新的原語類型。

JEP 草案 8301034，密鑰封裝機制API，一種 JEP 類型的特性，提議：滿足标準密鑰封裝機制（Key Encapsulation Mechanism，KEM）算法的實作；通過更進階别的安全協定滿足 KEM 的用例；并且允許可插拔的 KEM 算法的 Java 或本地實作。該草案最近進行了更新，其中包括一項重大更改，即取消了 DerivedKeyParameterSpec 類，轉而将字段放在 encapsulate(int from, int to, String algorithm) 方法的參數清單中。

JEP 草案 8283227，JDK源結構，一種資訊類的 JEP，用于描述 JDK 源代碼和 JDK 代碼庫中相關檔案的總體布局和結構。該 JEP 提議幫助開發人員适應在 JDK9 中提供的 JEP 201，子產品化源代碼中所描述的源代碼結構。

JEP 草案 8280389，ClassFile API，提議提供一個用于解析、生成和轉換 Java 類檔案的 API。該 JEP 最初将作為 JDK 中ASM（Java 位元組碼操作和分析架構）的内部替代品，并計劃将其作為公共 API 開放出來。甲骨文（Oracle）的 Java 語言架構師Brian Goetz将 ASM 描述為“一個帶有大量遺留包袱的舊代碼庫”，并提供了有關該草案将如何演進并最終取代 ASM 的背景資訊。

JEP 草案 8278252，JDK打包和安裝指南，一個資訊型的 JEP，提議為 macOS、Linux 和 Windows 提供建立 JDK 安裝程式的指南，以降低不同 JDK 提供程式在 JDK 安裝之間發生沖突的風險。其目的是通過規範化安裝目錄名稱、包名稱和其他可能導緻沖突的安裝程式元素，在安裝 JDK 更新版本時提升更好的使用者體驗。

我們預計甲骨文将會很快開始為 JDK 21 提供更多的額外 JEP。

原文連結：

https://www.infoq.com/news/2023/03/java-20-so-far/

相關閱讀：

Java 近期新聞：NetBeans 17、Spring 及 Tomcat 多項更新、JDk 20 版本 GraalVM

虛拟線程：大規模 Java 應用的新基石

Just：Spring Boot 應用的新指令行界面

本文轉載來源：

https://www.infoq.cn/article/o4cLTZJXMgC7pJwfA8og