點擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺回復(fù)"書"，獲取

后臺回復(fù)“k8s”，可領(lǐng)取k8s資料

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

JDK 17 現(xiàn)在已經(jīng)進入了第二個也是最后一個候選版本階段（RC），目前最新版本是 Build 35。

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

• Context-specific 反序列化過濾器允許應(yīng)用程序通過調(diào)用 JVM-wide filter factory 為每個序列化操作選擇過濾器，來配置 context-specific ?和 dynamically selected 的反序列化過濾器。

• 隨著 always-strict 浮點語義的恢復(fù)，浮點運算將保持一致的嚴格；而不是同時具有嚴格的浮點語義 (?strictfp) 和有著微妙出入的默認浮點語義。這就為語言和 VM 恢復(fù)了原始的浮點語義，與 Java Standard Edition 1.2 中引入嚴格和默認浮點模式之前的語義相匹配。

• 棄用 Security Manager，準(zhǔn)備在未來版本中移除。追溯到 Java 1.0，Security Manager 一直是保護客戶端 Java 代碼的主要手段，很少用于保護服務(wù)器端代碼。該提案的一個目標(biāo)是評估是否需要新的 API 或機制來解決使用 Security Manager 的特定狹窄用例，例如阻塞System::exit。計劃要求棄用 Security Manager 以與舊 Applet API 一起刪除，該 API 也計劃在 JDK 17 中棄用。

• switch模式匹配預(yù)覽版擴展了 Java 中的模式語言，允許switch表達式和語句可以針對多個模式進行測試，每個模式都有特定的操作。這使得復(fù)雜的面向數(shù)據(jù)的查詢能夠簡潔而安全地表達。此功能的目標(biāo)包括：通過使模式出現(xiàn)在案例標(biāo)簽中，來擴展switch表達式和語句的表現(xiàn)力和應(yīng)用，在需要時放寬switch的 historical null-hostility，并引入兩種模式：guarded patterns，允許用任意的布爾表達式來完善模式匹配邏輯，以及parenthesized patterns，解決了一些解析歧義。在 JDK 16 中，instanceof運算符被擴展為采用類型模式并執(zhí)行模式匹配。提議的適度擴展允許簡化熟悉的 instanceof-and-cast 習(xí)語。

• JDK 內(nèi)部的強封裝，除了sun.misc.Unsafe等關(guān)鍵的內(nèi)部 API 外，用戶將不再可能通過單個命令行選項來 relax 對內(nèi)部元素的強封裝，這在 JDK 9 到 JDK 16 中是可行的。該計劃的目標(biāo)包括提高 JDK 的安全性和可維護性，并鼓勵開發(fā)人員從內(nèi)部元素遷移到標(biāo)準(zhǔn) API。

• 刪除遠程方法調(diào)用 (RMI) 激活機制，同時保留 RMI 的其余部分。RMI 激活機制已過時和廢棄，在 JDK 15 中不推薦使用。

• 在外部函數(shù)和 memory API 引入了一個孵化器階段，允許 Java 程序與 Java 運行時之外的代碼和數(shù)據(jù)進行互操作。API 計劃的目標(biāo)包括易用性、性能、通用性和安全性。

• 與平臺無關(guān)的矢量 API 作為孵化 API 集成到 JDK 16 中，將在 JDK 17 中再次孵化，提供一種機制來表達矢量計算，這些計算在運行時可靠地編譯為支持的 CPU 架構(gòu)上的最佳矢量指令。這比等效的標(biāo)量計算獲得了更好的性能。在 JDK 17 中，向量 API 已針對性能和實現(xiàn)進行了增強，包括在字節(jié)向量與布爾數(shù)組之間進行轉(zhuǎn)換的增強功能。

• 密封類和接口限制哪些其他類或接口可以擴展或?qū)崿F(xiàn)它們。該提案的目標(biāo)包括允許類或接口的作者控制哪些代碼負責(zé)實現(xiàn)它，提供比訪問修飾符更具聲明性的方式來限制超類的使用，并通過為模式的詳盡分析提供基礎(chǔ)來支持模式匹配的未來方向。

• 刪除實驗性 AOT 和 JIT 編譯器，它們幾乎沒有使用，但需要大量維護工作。該計劃要求維護 Java 級別的 JVM 編譯器接口，以便開發(fā)人員可以繼續(xù)使用外部構(gòu)建的編譯器版本進行 JIT 編譯。

• 將 JDK 移植到 MacOS/AArch64 以響應(yīng) Apple 將其 Macintosh 計算機從 x64 轉(zhuǎn)換到 AArch64 的計劃。針對 MacOS/AArch64 的更改有可能破壞現(xiàn)有的 Linux/AArch64、Windows/AArch64 和 MacOS/x64 port，但這種風(fēng)險可通過預(yù)集成測試來降低。

• 棄用 Applet API 以進行刪除。這個 API 本質(zhì)上是無關(guān)緊要的，因為所有 Web 瀏覽器供應(yīng)商要么已經(jīng)取消了對 Java 瀏覽器插件的支持，要么已經(jīng)宣布了這樣做的計劃。Applet API 之前在 2017 年 9 月的 Java 9 中已被棄用，但并未刪除。

• 用于 MacOS 的新渲染管道，使用 Apple Metal API 作為使用已棄用 OpenGL API 的現(xiàn)有管道的替代方案。該提議旨在為使用 MacOS Metal 框架的 Java 2D API 提供一條功能齊全的渲染管道，為蘋果從未來版本的 MacOS 中刪除 OpenGL API 做好準(zhǔn)備。該管道旨在功能上與現(xiàn)有的 OpenGL 管道相當(dāng)，在某些應(yīng)用程序和基準(zhǔn)測試中具有相同或更好的性能。將創(chuàng)建適合當(dāng)前 Java 2D 模型的干凈架構(gòu)。管道將與 OpenGL 管道共存，直到被淘汰。本提案的目的并不是添加任何新的 Java 或 JDK API。

• 增強的偽隨機數(shù)生成器將為偽隨機數(shù)生成器（PRNG）提供新的接口類型和實現(xiàn)，包括可跳轉(zhuǎn)的 PRNG 和額外的一類可拆分 PRNG 算法 (LXM)。新接口RandomGenerator將為所有現(xiàn)有的和新的 PRNG 提供統(tǒng)一的 API；將提供四個專門的 RandomGenerator 接口。該計劃的動機是關(guān)注 Java 中偽隨機數(shù)生成領(lǐng)域的多個改進領(lǐng)域。這項工作不需要提供許多其他 PRNG 算法的實現(xiàn)。但是已經(jīng)添加了三種常用算法，這些算法已經(jīng)廣泛部署在其他編程語言環(huán)境中。該計劃的目標(biāo)包括：

• • 使在應(yīng)用程序中交替使用各種 PRNG 算法變得更容易。

  • 改進了對基于流的編程的支持，提供了 PRNG 對象流。

  • 消除現(xiàn)有 PRNG 類中的代碼重復(fù)。

  • 保留類java.util.Random的現(xiàn)有行為。

JDK 17 等 LTS 版本每三年發(fā)布一次，上一個LTS 版本?JDK 11?于 2018 年 9 月發(fā)布。

詳情可查看：https://jdk.java.net/17/?

想知道更多？掃描下面的二維碼關(guān)注我后臺回復(fù)"技術(shù)"，加入技術(shù)群后臺回復(fù)“k8s”，可領(lǐng)取k8s資料【精彩推薦】

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數(shù)據(jù)？

• 架構(gòu)之道：分離業(yè)務(wù)邏輯和技術(shù)細節(jié)

• 星巴克不使用兩階段提交

• 面試官：Redis新版本開始引入多線程，談?wù)勀愕目捶?#xff1f;

• 喜馬拉雅自研網(wǎng)關(guān)架構(gòu)演進過程

• 收藏：存儲知識全面總結(jié)

• 微博千萬級規(guī)模高性能高并發(fā)的網(wǎng)絡(luò)架構(gòu)設(shè)計

總結(jié)

以上是生活随笔為你收集整理的JDK/Java 17 可能带来什么新特性？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。