JDK 17：Java 17 中的新特性 - InfoWorld

banq發表於2021-06-09
JDKJava

Java 開發工具包 (JDK) 17 將是一個長期支援 (LTS) 版本，預計來自 Oracle 的擴充套件支援將持續數年。該功能集定於 6 月 10 日凍結，屆時 JDK 17 將進入初始階段。作為 OpenJDK JDK 17 的一部分提交的功能包括： 
  • 特定於上下文的反序列化過濾器允許應用程式透過呼叫 JVM 範圍的過濾器工廠來配置特定於上下文和動態選擇的反序列化過濾器，以便為每個序列化操作選擇一個過濾器。在解釋該提議背後的動機時，Oracle 表示反序列化不受信任的資料是一種固有的危險活動，因為傳入資料流的內容決定了建立的物件、其欄位的值以及它們之間的引用。在許多用途中，流中的位元組是從未知、不受信任或未經身份驗證的客戶端接收的。透過仔細構建流，攻擊者可以導致惡意執行任意類中的程式碼。如果物件構造具有改變狀態或呼叫其他操作的副作用，則這些操作可能會危及應用程式物件的完整性，庫物件和 Java 執行時。禁用序列化攻擊的關鍵是防止任意類的例項被反序列化，從而防止直接或間接執行它們的方法。反序列化過濾器被引入Java 9使應用程式和庫程式碼能夠在反序列化之前驗證傳入的資料流。
    程式碼java.io.ObjectInputFilter在建立反序列化流時提供驗證邏輯。但是，依賴流的建立者來明確請求驗證有侷限性。JDK Enhancement Proposal 290透過引入可透過 API、系統屬性或安全屬性設定的 JVM 範圍的反序列化過濾器解決了這些限制，但這種方法也有侷限性，尤其是在複雜的應用程式中。更好的方法是配置每個流過濾器，這樣它們就不需要每個流建立者的參與。計劃中的增強應幫助開發人員為每個反序列化上下文和用例構建和應用適當的過濾器。
  • 隨著always-strict 浮點語義的恢復，浮點運算將變得始終嚴格，而不是同時具有嚴格浮點語義 ( strictfp) 和微妙不同的預設浮點語義。這將原始浮點語義恢復到語言和 VM中，匹配 Java 標準版 1.2 中引入嚴格和預設浮點模式之前的語義。這項工作的目標包括簡化數字敏感庫的開發，包括java.lang.Math和java.lang.StrictMath. 
    改變預設浮點語義的動力來自於原始Java語言和JVM語義之間的不良互動作用，以及流行的x86體系結構的x87浮點協處理器指令集的一些特性。在所有情況下匹配精確的浮點語義，包括非正規運算元和結果，需要大量額外指令的開銷。在沒有溢位或下溢的情況下匹配結果可以用較少的開銷完成，而這正是javase1.2中引入的修改後的預設浮點語義所允許的。但是，大約從2001年開始在奔騰4和更高版本的處理器中釋出的SSE2（第二代資料流單指令多資料擴充套件指令集）擴充套件可以以一種簡單的方式支援嚴格的JVM浮點操作，而不會產生過多的開銷。由於Intel和AMD支援SSE2和更高版本的擴充套件，這些擴充套件允許自然地支援嚴格浮點語義，因此使用不同於strict的預設浮點語義的技術動機已不復存在。
  • 棄用安全管理器，準備在未來版本中移除。追溯到 Java 1.0，安全管理器一直是保護客戶端 Java 程式碼的主要手段，很少用於保護伺服器端程式碼。該提案的一個目標是評估是否需要新的 API 或機制來解決使用安全管理器的特定狹窄用例，例如阻塞System::exit。計劃要求棄用安全管理器以與舊 Applet API 一起刪除，該 API 也計劃在 JDK 17 中棄用。
  • 模式匹配switch預覽版擴充套件了 Java 中的模式語言，允許switch針對多個模式測試表示式和語句，每個模式都有特定的操作。這使得複雜的面向資料的查詢能夠簡潔而安全地表達。
    此功能的目標包括擴充套件轉換表示式和語句允許模式出現在case標籤中，減輕了轉換如果需要，引入兩種模式：guarded patterns允許使用任意布林表示式對模式匹配邏輯進行最佳化，以及parenthesized patterns解決了一些解析歧義。
    在JDK 16，的運算子運算子被擴充套件為獲取型別模式並執行模式匹配。提議的適度擴充套件允許簡化熟悉的instanceof和cast習慣用法。
  • JDK 內部的強封裝，除了關鍵的內部 API，如sun.misc.Unsafe，將不再可能透過單個命令列選項放鬆內部元素的強封裝，這在 JDK 9 到 JDK 16 中是可行的。計劃包括提高 JDK 的安全性和可維護性，並鼓勵開發人員從內部元素遷移到標準 API。
  • 刪除遠端方法呼叫 (RMI) 啟用機制，同時保留 RMI 的其餘部分。RMI 啟用機制已過時和廢棄，在JDK 15 中不推薦使用。
  • 在外部函式和記憶體API引入了一個孵化器階段，允許 Java 程式與 Java 執行時之外的程式碼和資料進行互操作。透過高效呼叫外部函式，即 JVM 之外的程式碼，安全訪問外部記憶體，即非 JVM 管理的記憶體，API 使 Java 程式能夠呼叫本地庫和處理本地資料，而沒有JNI（Java本機介面）的脆弱性和風險。
    提議的 API 是兩個 API 的演變：外部記憶體訪問 API 和外部連結器 API。
    外部記憶體訪問 API 在 2019 年作為孵化 API 面向 Java 14，並在 Java 15 和 Java 16 中重新孵化。外部連結器 API 在 2020 年末面向 Java 16 作為孵化 API。API 計劃的目標包括易用性、效能、通用性和安全性。
  • 與平臺無關的向量 API作為孵化 API整合到JDK 16中，將在 JDK 17 中再次孵化，提供一種機制來表達向量計算，這些計算在執行時可靠地編譯為支援的 CPU 架構上的最佳向量指令。這比等效的標量計算獲得了更好的效能。在 JDK 17 中，向量 API 已針對效能和實現進行了增強，包括在位元組向量與布林陣列之間進行轉換的增強功能。
  • 密封類和介面限制哪些其他類或介面可以擴充套件或實現它們。該提案的目標包括允許類或介面的作者控制由哪些程式碼負責實現它，提供一種比訪問修飾符更具宣告性的方式來限制超類的使用，並透過為模式的詳盡分析提供基礎來支援模式匹配的未來方向。
  • 刪除實驗性 AOT 和 JIT 編譯器，它們幾乎沒有使用，但需要大量維護工作。該計劃要求維護 Java 級別的 JVM 編譯器介面，以便開發人員可以繼續使用外部構建的編譯器版本進行 JIT 編譯。AOT 編譯（jaotc 工具）作為一個實驗性特性被整合到JDK 9中。該工具使用Graal 編譯器，它本身是用 Java 編寫的，用於 AOT 編譯。這些實驗性功能未包含在JDK 16 中由 Oracle 釋出的版本，沒有人抱怨。根據規定的計劃，將刪除三個 JDK 模組： jdk.aot（jaotc 工具）；internal.vm.compiler，Graal 編譯器；和 jdk.internal.vm.compiler.management，Graal MBean。與 AOT 編譯相關的 HotSpot 程式碼也將被刪除。
  • 將 JDK 移植到 MacOS/AArch64以響應Apple 將其 Macintosh 計算機從 x64 轉換到 AArch64 的計劃。適用於 Linux 的 Java 的 AArch64 埠已經存在，並且 Windows 的工作正在進行中。Java 構建者希望透過使用條件編譯來重用來自這些埠的現有 AArch64 程式碼，這是 JDK 埠中的規範，以適應低階約定的差異，例如應用程式二進位制介面和一組保留的處理器暫存器。MacOS/AArch64 的更改可能會破壞現有的 Linux/AArch64、Windows/AArch64 和 MacOS/x64 埠，但透過預整合測試將降低風險。
  • 棄用 Applet API 以進行刪除。這個 API 本質上是無關緊要的，因為所有 Web 瀏覽器供應商要麼已經取消了對 Java 瀏覽器外掛的支援，要麼已經宣佈了這樣做的計劃。Applet API 之前在 2017 年 9 月的Java 9中已被棄用，但並未刪除。
  • 用於 MacOS 的新渲染管道，使用 Apple Metal API 作為使用已棄用 OpenGL API 的現有管道的替代方案。該提案旨在為使用 MacOS Metal 框架的 Java 2D API 提供功能齊全的渲染管道，並在 Apple 從未來版本的 MacOS 中刪除 OpenGL API 時做好準備。該管道旨在與現有的 OpenGL 管道具有同等功能，在選定的應用程式和基準測試中具有相同或更好的效能。將建立適合當前 Java 2D 模型的乾淨架構。管道將與 OpenGL 管道共存直到過時。新增任何新的 Java 或 JDK API 並不是提案的目標。
  • 增強的偽隨機數生成器將為偽隨機數生成器 (PRNG) 提供新的介面型別和實現，包括可跳轉的 PRNG 和額外的一類可拆分 PRNG 演算法 (LXM)。新介面RandomGenerator將為所有現有的和新的 PRNG 提供統一的 API。將提供四個專門的 RandomGenerator 介面。推動該計劃的重點是 Java 偽隨機數生成領域的多個改進領域。這項工作不需要提供許多其他 PRNG 演算法的實現。但是已經新增了三種常用演算法，這些演算法已經廣泛部署在其他程式語言環境中。該計劃的目標包括：
    • 使在應用程式中交替使用各種 PRNG 演算法變得更容易。
    • 改進了對基於流的程式設計的支援，提供了 PRNG 物件流。
    • 消除現有 PRNG 類中的程式碼重複。
    • 保留類的現有行為java.util.Random。

9 月 14 日已被定為 JDK 17 的全面可用日期。生產版本之前將在 6 月和 7 月進行斜降階段，並在 8 月釋出候選版本。JDK 17 的早期訪問開源版本可以在jdk.java.net上找到。
JDK 17 等 LTS 版本每三年釋出一次。最後一個 LTS 版本JDK 11於 2018 年 9 月釋出。 Java 的新版本每六個月釋出一次。

相關文章