JDK/Java 17 可能帶來什麼新特性？

點擊關注公衆號，Java乾貨及時送達

文 | 白開水

出品 | OSC開源社區（ID：oschina2013）

JDK/Java 16 已於今年 3 月份正式 GA，這是一個短期維護版本，僅有 6 個月的技術支持。下一個版本 JDK/Java 17 計劃於今年 9 月 14 日發佈，這是一個長期支持（LTS）版本，預計 Oracle 將提供數年的擴展支持。

JDK 17 現在已經進入了第二個也是最後一個候選版本階段（RC），目前最新版本是 Build 35。

按 InfoWorld 所述，OpenJDK JDK 17 的部分功能包括有：

Context-specific 反序列化過濾器允許應用程序通過調用 JVM-wide filter factory 爲每個序列化操作選擇過濾器，來配置 context-specific 和 dynamically selected 的反序列化過濾器。
隨着 always-strict 浮點語義的恢復，浮點運算將保持一致的嚴格；而不是同時具有嚴格的浮點語義 ( strictfp) 和有着微妙出入的默認浮點語義。這就爲語言和 VM 恢復了原始的浮點語義，與 Java Standard Edition 1.2 中引入嚴格和默認浮點模式之前的語義相匹配。
棄用 Security Manager，準備在未來版本中移除。追溯到 Java 1.0，Security Manager 一直是保護客戶端 Java 代碼的主要手段，很少用於保護服務器端代碼。該提案的一個目標是評估是否需要新的 API 或機制來解決使用 Security Manager 的特定狹窄用例，例如阻塞System::exit。計劃要求棄用 Security Manager 以與舊 Applet API 一起刪除，該 API 也計劃在 JDK 17 中棄用。
switch模式匹配預覽版擴展了 Java 中的模式語言，允許switch表達式和語句可以針對多個模式進行測試，每個模式都有特定的操作。這使得複雜的面向數據的查詢能夠簡潔而安全地表達。此功能的目標包括：通過使模式出現在案例標籤中，來擴展switch表達式和語句的表現力和應用，在需要時放寬switch的 historical null-hostility，並引入兩種模式：guarded patterns，允許用任意的布爾表達式來完善模式匹配邏輯，以及parenthesized patterns，解決了一些解析歧義。在 JDK 16 中，instanceof運算符被擴展爲採用類型模式並執行模式匹配。提議的適度擴展允許簡化熟悉的 instanceof-and-cast 習語。
JDK 內部的強封裝，除了sun.misc.Unsafe等關鍵的內部 API 外，用戶將不再可能通過單個命令行選項來 relax 對內部元素的強封裝，這在 JDK 9 到 JDK 16 中是可行的。該計劃的目標包括提高 JDK 的安全性和可維護性，並鼓勵開發人員從內部元素遷移到標準 API。
刪除遠程方法調用 (RMI) 激活機制，同時保留 RMI 的其餘部分。RMI 激活機制已過時和廢棄，在 JDK 15 中不推薦使用。
在外部函數和 memory API 引入了一個孵化器階段，允許 Java 程序與 Java 運行時之外的代碼和數據進行互操作。API 計劃的目標包括易用性、性能、通用性和安全性。
與平臺無關的矢量 API 作爲孵化 API 集成到 JDK 16 中，將在 JDK 17 中再次孵化，提供一種機制來表達矢量計算，這些計算在運行時可靠地編譯爲支持的 CPU 架構上的最佳矢量指令。這比等效的標量計算獲得了更好的性能。在 JDK 17 中，向量 API 已針對性能和實現進行了增強，包括在字節向量與布爾數組之間進行轉換的增強功能。
密封類和接口限制哪些其他類或接口可以擴展或實現它們。該提案的目標包括允許類或接口的作者控制哪些代碼負責實現它，提供比訪問修飾符更具聲明性的方式來限制超類的使用，並通過爲模式的詳盡分析提供基礎來支持模式匹配的未來方向。
刪除實驗性 AOT 和 JIT 編譯器，它們幾乎沒有使用，但需要大量維護工作。該計劃要求維護 Java 級別的 JVM 編譯器接口，以便開發人員可以繼續使用外部構建的編譯器版本進行 JIT 編譯。
將 JDK 移植到 MacOS/AArch64 以響應 Apple 將其 Macintosh 計算機從 x64 轉換到 AArch64 的計劃。針對 MacOS/AArch64 的更改有可能破壞現有的 Linux/AArch64、Windows/AArch64 和 MacOS/x64 port，但這種風險可通過預集成測試來降低。
棄用 Applet API 以進行刪除。這個 API 本質上是無關緊要的，因爲所有 Web 瀏覽器供應商要麼已經取消了對 Java 瀏覽器插件的支持，要麼已經宣佈了這樣做的計劃。Applet API 之前在 2017 年 9 月的 Java 9 中已被棄用，但並未刪除。
用於 MacOS 的新渲染管道，使用 Apple Metal API 作爲使用已棄用 OpenGL API 的現有管道的替代方案。該提議旨在爲使用 MacOS Metal 框架的 Java 2D API 提供一條功能齊全的渲染管道，爲蘋果從未來版本的 MacOS 中刪除 OpenGL API 做好準備。該管道旨在功能上與現有的 OpenGL 管道相當，在某些應用程序和基準測試中具有相同或更好的性能。將創建適合當前 Java 2D 模型的乾淨架構。管道將與 OpenGL 管道共存，直到被淘汰。本提案的目的並不是添加任何新的 Java 或 JDK API。
增強的僞隨機數生成器將爲僞隨機數生成器（PRNG）提供新的接口類型和實現，包括可跳轉的 PRNG 和額外的一類可拆分 PRNG 算法 (LXM)。新接口RandomGenerator將爲所有現有的和新的 PRNG 提供統一的 API；將提供四個專門的 RandomGenerator 接口。該計劃的動機是關注 Java 中僞隨機數生成領域的多個改進領域。這項工作不需要提供許多其他 PRNG 算法的實現。但是已經添加了三種常用算法，這些算法已經廣泛部署在其他編程語言環境中。該計劃的目標包括：