背景
定于9月推出的Java21計劃現(xiàn)在包括一個關鍵封裝機制API和32位Windows端口的棄用。
Java開發(fā)工具包(JDK)21將于9月作為Oracle標準Java實現(xiàn)的下一個長期支持版本,現(xiàn)在有13個功能被正式提出,最近幾天又增加了兩個功能。
最新的提議包括密鑰封裝機制(KEM)API和32位x86 Windows端口的棄用。本月早些時候,還添加了其他三個功能,即代Shenandoah垃圾收集器、未命名類和實例主方法以及未命名模式和變量。
這五個建議結合了3月和4月提出的八個功能:一代ZGC(Z垃圾收集器)、記錄模式、switch表達式和語句的模式匹配、向量API、序列化集合、虛擬線程、字符串模板預覽以及外部函數(shù)和內存API的第三個預覽。另外,JDK 21還將改變Windows上網(wǎng)絡接口的網(wǎng)絡名稱分配方式。
GPL下的早期訪問二進制文件可在jdk.java.net上獲得。Oracle每六個月發(fā)布一次標準java的新版本,最近的jdk 20已于3月21日發(fā)布。到目前為止,JDK 21的具體建議包括:
-
密鑰封裝機制API
,一種通過公共加密來保護對稱密鑰的加密技術。該提案的一個目標是使應用程序能夠使用KEM算法,如RSA密鑰封裝機制(RSA-KEM)、橢圓曲線集成加密方案(ECIES),以及美國國家標準與技術研究所(NIST)后量子密碼學標準化過程的候選算法。另一個目標是使KEM能夠在更高級別的協(xié)議(如傳輸層安全性(TLS))和加密方案(如混合公鑰加密(HPKE))中使用。此外,安全提供商將能夠在Java代碼或本機代碼中實現(xiàn)KEM算法,并包括在RFC 9180中定義的Diffie-Hellman KEM(DHKEM)的實現(xiàn)。 -
不推薦刪除Windows 32位x86端口
,目標是在將來的版本中刪除它。該提案旨在更新生成系統(tǒng),以便在嘗試為Windows 32位x86配置生成時發(fā)出錯誤消息。該消息將通過新的配置選項被抑制。此外,計劃將端口和相關端口特定功能標記為不推薦在相關文檔中刪除。該提案指出,Windows 10是最后一款支持32位操作的Windows操作系統(tǒng),將于2025年10月停止使用。 -
Generational Shenandoah
,一項旨在增強Shenandoh GC的提案,具有實驗性的代收集能力,以提高可持續(xù)吞吐量、負載峰值彈性和內存利用率。該提案的主要目標是在不打破非世代Shenandoah的情況下提供一種實驗性的世代模式,目的是在未來的版本中使世代模式成為默認模式。其他目標包括在不犧牲低GC暫停的情況下減少持續(xù)的內存占用,減少CPU和功耗,保持高吞吐量,以及繼續(xù)支持壓縮對象指針。該提案最初將支持x64和AArch64,并隨著實驗模式的發(fā)展而增加對其他指令集的支持。它的目標不是取代非世代的Shenandoah,它將繼續(xù)作為默認的操作模式,其性能或功能不會倒退。提高每一個可以想象的工作量的性能也不是一個目標。 -
預覽未命名的類和實例主方法
,以發(fā)展語言,使學生能夠編寫他們的第一個Java程序,而無需理解為大型程序設計的語言功能。學生們可以為單類程序編寫精簡的聲明,而不是使用單獨的Java方言,然后隨著技能的發(fā)展,無縫地擴展程序以使用更高級的功能。其目的是為Java提供一個平滑的入口。 -
未命名模式和變量的預覽
,以使用未命名的模式和未命名的變量增強語言。未命名的模式匹配記錄組件,而不說明組件的名稱或類型,而未命名的變量可以初始化但不能使用。兩者都用下劃線字符_表示。該建議旨在通過消除不必要的嵌套模式來提高記錄模式的可讀性,并通過識別必須聲明但不會使用的變量來提高所有代碼的可維護性。 -
Generational ZGC
旨在通過擴展ZGC來為新對象和舊對象保持獨立的生成,從而提高應用程序性能。年輕的物體往往英年早逝,保持不同的世代將使ZGC能夠更頻繁地收集它們。使用世代ZGC運行的應用程序應該看到以下好處:更低的分配停滯風險、更低的堆內存開銷和更低的垃圾收集CPU開銷。與非世代ZGC相比,這些好處應該不會顯著降低吞吐量。 - JDK19和JDK20中預覽的
記錄模式
將解構記錄值??梢郧短子涗浤J胶皖愋湍J?,以實現(xiàn)強大、聲明性和可組合形式的數(shù)據(jù)導航和處理。該提案的目標包括擴展模式匹配以銷毀記錄類的實例,并添加嵌套模式,從而實現(xiàn)更可組合的數(shù)據(jù)查詢。此功能與交換機的模式匹配共同發(fā)展。當前JEP(JDK Enhancement Proposal)中的記錄模式建議在持續(xù)的經驗和反饋的基礎上進一步完善該功能。除了小的編輯更改外,自第二次預覽以來的主要更改是刪除了對出現(xiàn)在增強的for語句標題中的記錄模式的支持。該功能可能會在未來的JEP中重新提出。 -
switch的模式匹配
使switch表達式或語句能夠針對多個模式進行測試,每個模式都有特定的操作,因此可以安全簡潔地表達復雜的面向數(shù)據(jù)的查詢。這個特性最初是在JDK17中提出的,后來在JDK18、JDK19和JDK20中進行了改進。它將在JDK 21中最終確定,并根據(jù)反饋和經驗進行進一步改進。與以前的JEP相比,主要的變化是刪除了帶括號的模式,并允許使用限定的枚舉常量,如帶有開關表達式和語句的case常量。目標包括通過允許模式出現(xiàn)在case標簽中來擴展switch表達式和語句的表達性和適用性,允許在需要時放松switch的歷史null敵意,并通過要求模式switch語句覆蓋所有潛在輸入值來提高switch語句的安全性。另一個目標是確?,F(xiàn)有的switch表達式和語句在沒有任何更改的情況下繼續(xù)編譯,并以相同的語義執(zhí)行。 -
Vector API
的第六個孵化器,用于表達向量計算,這些計算在運行時可靠地編譯為支持的CPU體系結構上的最優(yōu)向量指令,實現(xiàn)優(yōu)于等效標量計算的性能。這之前已經在JDK16到JDK20中進行了培育。最新版本包括性能增強和錯誤修復。該提案的目標包括清晰簡潔,與平臺無關,并在x64和AArch64架構上提供可靠的運行時編譯和性能。其他目標包括優(yōu)雅的降級,當矢量計算在運行時不能完全表示為矢量指令序列時,以及與Project Valhalla保持一致。 -
外部函數(shù)和內存API
使Java程序能夠與Java運行時之外的代碼和數(shù)據(jù)進行互操作。通過有效調用外部函數(shù)和安全訪問外部內存,此預覽API使Java程序能夠調用本機庫并處理本機數(shù)據(jù),而不會出現(xiàn)JNI(Java native Interface)的脆弱性和危險性。API之前在上個月首次亮相的JDK 20和2022年9月發(fā)布的JDK 19中進行了預覽。最新預覽中的改進包括使用新元素來取消引用地址布局的增強布局路徑、對Arena接口中本地段的生存期的集中管理、回退本地鏈接器實現(xiàn)以及刪除VaList。該提案的目標包括易用性、性能、通用性和安全性。在這個API之上重新實現(xiàn)JNI或以任何方式更改JNI都不是我們的目標。 -
虛擬線程
是輕量級線程,承諾“顯著”減少編寫、維護和觀察高吞吐量并發(fā)應用程序的工作量。該計劃的目標包括使以簡單線程請求方式編寫的服務器應用程序能夠以接近最佳的硬件利用率進行擴展,使使用lang.thread API的現(xiàn)有代碼能夠采用變化最小的虛擬線程,并使用當前JDK工具輕松調試和分析虛擬線程。之前在JDK20和JDK19中預覽過,虛擬線程將在JDK21中最終確定。有了JDK21,虛擬線程現(xiàn)在一直支持線程本地變量,這使得不可能創(chuàng)建沒有這些變量的虛擬線程。對線程本地變量的有保證的支持確保了更多的現(xiàn)有庫可以與虛擬線程一起使用,并有助于遷移面向任務的代碼以使用虛擬線程。 -
序列集合
引入了接口來表示具有定義的相遇順序的集合。每個集合都有定義明確的第一和第二元素,依此類推,直到最后一個元素。提供了統(tǒng)一的API來接受第一個和最后一個元素,并以相反的順序處理元素。該提議的動機是Java的集合框架缺乏一種集合類型來表示具有定義的相遇順序的元素序列。它還缺乏一套適用于這些集合的統(tǒng)一操作。這些差距一直是一個問題,也是投訴的根源。該提案要求定義集合、集合和映射的排序接口,并將其改造為現(xiàn)有的集合類型層次結構。所有這些新方法都有默認實現(xiàn)。 -
字符串模板
作為預覽功能出現(xiàn),通過將文本與嵌入的表達式和處理器耦合以產生專門的結果,來補充Java現(xiàn)有的字符串文本和文本塊。此語言功能和API旨在簡化Java程序的編寫,使其易于表達包含運行時計算的值的字符串。它承諾增強表達式的可讀性,提高程序安全性,保持靈活性,并簡化接受用非Java語言編寫的字符串的API的使用。實現(xiàn)從結合文字文本和嵌入表達式派生的非字符串表達式的開發(fā)也是一個目標。
Oracle的Java團隊表示,除了這些JEP之外,JDK為Windows上的網(wǎng)絡接口分配的網(wǎng)絡名稱將在JDK 21中更改。建議進行網(wǎng)絡多播或使用java.net.NetworkInterface API的應用程序的維護人員注意這一更改。
JDK歷史上合成了Windows上網(wǎng)絡接口的名稱。此名稱已更改為使用Windows操作系統(tǒng)指定的名稱。更改可能會影響使用NetworkInterface.GgetbyName(字符串名稱)方法查找網(wǎng)絡接口的代碼。
JDK21的發(fā)布計劃包括6月8日和7月20日的逐步減少階段。該功能集在第一個漸變階段被凍結,同時錯誤修復仍在繼續(xù)。接下來是8月10日和8月24日的首次和最終候選版本,仍然可以修復錯誤,然后在9月19日正式發(fā)布。
作為一個長期支持(LTS)版本,JDK 21將獲得五年的卓越支持,并將支持延長至2031年9月。當前的LTS版本是JDK 17,發(fā)布于2021年9月。非LTS版本,如JDK20和JDK19,只獲得六個月的首要支持,沒有擴展支持。
JDK21還可以添加一些其他潛在的功能。一個是預覽用于在線程內和線程間共享不可變數(shù)據(jù)的作用域值。這個特性是在JDK 20中培育出來的。第二種可能性是分級結構化并發(fā),這是一種簡化錯誤處理和提高可靠性的建議,用于預覽狀態(tài)。這個特性以前是在JDK19和JDK20中培育出來的。文章來源:http://www.zghlxwxcb.cn/news/detail-467615.html
準備禁止動態(tài)加載代理的功能是第三種可能性。當代理被動態(tài)加載到正在運行的JVM中時,此功能將發(fā)出警告,為默認情況下不允許加載動態(tài)代理的未來版本做準備。最后,JDK21的第四個潛在特性是一個實驗性的緊湊對象頭功能,旨在減少JVM中對象頭的大小,以減少堆大小。文章來源地址http://www.zghlxwxcb.cn/news/detail-467615.html
到了這里,關于JDK21:Java21的新特性的文章就介紹完了。如果您還想了解更多內容,請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章,希望大家以后多多支持TOY模板網(wǎng)!