Java 21正式發佈 新增虛擬線程、AI接口 最新LTS版本支持8年

9月9日,Ocle 公司宣佈推出 J2的正式版本,以及相應的 JDK 2 開發工具包,該版本是繼 JDK 7 之後最新的長期支持(LTS)版本,將獲得至少 8 年的支持。同時還宣佈對五年前發佈的 J 的長期支持已延長至 2032 年 月。

在最新的J 2 版本中, Ocle 開發團隊爲其帶來了5大功能更新,詳細如下:

、字符串模板(預覽階段)

該功能通過將文字文本與嵌入式表達式和處理器相結合來產生專門的結果,從而補充了 J 現有的字符串文字和文本塊。該語言功能和 API 的目的是通過輕鬆表達包含運行時計算值的字符串來簡化 J 程序的編寫。它有望增強表達式的可讀性,提高程序的安全性,保持靈活性,並簡化接受用非 J 語言編寫的字符串的 API 的使用。

2、 序列集合

有序集合提案引入了一些接口,用於表示具有已定義遇到順序的集合。每個集合都有明確定義的第一個和第二個元素,以此類推,直到最後一箇元素。提供了一致的 API,用於接受第一個和最後一箇元素以及以相反順序處理元素。該提案的提出的原因是,J 的集合框架缺乏一種表示具有定義的遇到順序的元素序列的集合類型。它還缺乏適用於這些集合的一致的操作集。該提案要求定義順序集合、集合和映射的接口,並將這些接口適應到現有的集合類型層次結構中。所有這些新方法都具有默認實現。

3、加入 Genetionl ZGC

分代 ZGC 的目的是通過擴展 ZGC,維護新舊對象的不同代,從而提高應用程序的性能。年輕的對象往往很早就會死亡;保持獨立的世代將允許 ZGC 更頻繁地收集年輕對象。使用分代 ZGC 運行的應用程序應能獲得以下優勢:降低分配停滯的風險、降低堆內存開銷和降低垃圾回收 CPU 開銷。與非分代 ZGC 相比,這些優勢應該可以實現,而不會顯著降低吞吐量。

4、記錄模式

該功能在 JDK 9 和 JDK 20 中都是預覽版,主要用於解構記錄值。記錄模式和類型模式可以嵌套,以實現強大、聲明性和可組合的數據導航和處理形式。該提案的目標包括將模式匹配擴展到重組記錄類實例,並添加嵌套模式,從而實現更多可組合的數據查詢。當前 JEP(JDK 增強提案)中的記錄模式提案將最終確定該功能,並根據不斷積累的經驗和反饋意見進一步完善。

5、switch 模式匹配

該功能允許 switch 表達式或語句可以根據多箇模式(每個模式都有特定的操作)進行測試,從而可以安全、簡潔地表達面向數據的複雜查詢。該功能最初在 JDK 7 中提出,隨後在 JDK 8、JDK 9 和 JDK 20 中得到改進。它將在 JDK 2 中最終完成,並根據反饋和經驗進一步完善。與以前的 JEP 相比,主要的變化是刪除了括號模式,並允許使用限定的枚舉常量(如帶有 switch 表達式和語句的 cse 常量)。

6、外部函數與內存 API(第三次預覽)

允許 J 程序與 J 運行時之外的代碼和數據進行互操作。通過有效地調用外部函數和安全訪問外部內存,該 API 使 J 程序能夠調用本地庫並處理本機數據,而不會出現 JNI(J Ntie Intefce)的脆弱性和危險性。該 API 先前在 JDK 20 和 JDK 9 中進行了預覽。JDK 2 預覽中的改進包括增強的佈局路徑,增加了一箇用於取消引用地址佈局的新元素,以及集中管理 Aen 接口中本地段的生命週期;實現了一箇後備本地鏈接器;刪除了 VList。

7、未命名模式和變量(預覽版)

未命名模式匹配記錄組件,但不說明組件名稱或類型,而未命名變量可以初始化但不能使用。兩者都用下劃線字符 _ 表示。該提案旨在通過省略不必要的嵌套模式來提高記錄模式的可讀性,並通過識別必須聲明但不會使用的變量來提高所有代碼的可維護性。

8、虛擬線程

虛擬線程是一種輕量級線程,有望大幅減少編寫、維護和觀察高吞吐量併發應用程序的工作量。在 JDK 2 中,虛擬線程將始終支持線程本地變量,並使創建不具備這些變量的虛擬線程成爲不可能。對線程本地變量的有保證的支持確保更多的現有庫可以不改變地與虛擬線程一起使用,並幫助遷移任務導向的代碼以使用虛擬線程。

9、未命名類和實例主要方法(處於預覽階段)

該功能的作用是爲了讓學生能夠更容易地編寫出第一個 J 程序,而無需瞭解爲大型程序設計的語言功能。學生無需使用單獨的 J 方言,就能編寫單類程序的精簡聲明,然後隨着技能的提高,無縫擴展程序,使用更高級的功能。該提案不僅爲學生提供了通往 J 的平坦道路,還減少了編寫腳本和命令行實用程序等簡單 J 程序的繁瑣過程。

、作用域值(處於預覽階段)

作用域值(Scoped lues)是指允許在線程內和線程間共享不可變數據。作用域值允許在大型程序的組件之間安全地共享數據,而無需使用方法參數。這一提議在 JDK 20 中得到了驗證。該計劃的目標包括易用性、可理解性、健壯性和性能。

、矢量 API(第六個孵化器)

該 API 表達的矢量計算可在支持的 CPU 架構上可靠地編譯爲最佳矢量指令,從而實現優於同等標量計算的性能。此前,矢量 API 已在 JDK 6 至 JDK 20 中孵化。最新版本包括性能增強和錯誤修復。該提案的目標包括:簡潔明瞭、與平臺無關、在 x64 和 AAch64 體系結構上提供可靠的運行時編譯和性能。

2、 棄用 Windows 32 位 x86 端口

這個功能更新的目的是在未來的版本中刪除該端口。該提案旨在更新構建系統,以便在嘗試爲 32 位 x86 Windows 配置構建時,發出錯誤消息。該提案指出,支持 32 位操作的最後一箇 Windows 操作系統版本之 Windows 0 將於 2025 年 0 月終止生命週期。

3、 禁止代理的動態加載

當代理被動態加載到運行中的 JVM 時發出警告。發出這些警告的目的是爲將來發布默認禁止加載代理的版本做準備,以改善默認情況下的完整性。該提案的其他目標包括重新評估服務性(涉及對運行中代碼的臨時更改)和完整性(假定運行中的代碼不會被隨意更改)之間的平衡,並確保大多數不需要動態加載代理的工具不受影響。從 JDK 2 開始,計劃要求應用程序所有者批准動態加載代理,就像啓動時加載代理一樣。這個改變將使 J 平臺更接近默認情況下的完整性。

4 、密鑰封裝機制的 API

這一種通過公開密碼學保護對稱密鑰的加密技術。該提案的一箇目標是使應用程序能夠使用 KEM 算法,如 RSA 密鑰封裝機制(RSA-KEM)、橢圓曲線集成加密方案(ECIES)和美國國家標準與技術研究院(NIST)後量子密碼標準化過程的候選算法。另一箇目標是在更高級別的協議(如傳輸層安全性(TLS))和密碼方案(如混合公鑰加密(HPKE))中使用 KEM。安全提供商可以在 J 代碼或本地代碼中實現 KEM 算法,幷包括在 RFC 980 中定義的 Diffie-Hellmn KEM(DHKEM)的實現。

5、 結構化併發(目前處於預覽階段)

通過結構化併發 API 簡化併發編程,將在不同線程中運行的相關任務組視爲單個工作單元。這簡化了錯誤處理和取消操作,提高了可靠性並增強了可觀察性。結構化併發之前分別於 2022 年 3 月和 9 月在 JDK 20 和 JDK 9 中孵化,它作爲 j.util.concuent 包中的一箇預覽 API。這次唯一的重大變化是,StuctuedTskScope::Fok(…) 方法返回的是 [Subtsk] 而不是 Futue。結構化併發的目標包括促進一種併發編程風格,這種風格可以消除因取消和關閉而產生的常見風險(如線程泄漏和取消延遲),同時提高併發代碼的可觀察性。