作者 | 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