jep290涉及jdk版本

Mark Reinhold最近的消息宣布了六個新的“建議針對JDK 14的JEP ”： JEP 345 ， JEP 361 ， JEP 363 ， JEP 364 ， JEP 365和JEP 367 。 假設沒有異議由11月7日提出，這些JEPs將有針對性地JDK 14與之前定位JEPs沿JEP 349 （“JFR事件流”）， JEP 352 （“非揮發性映射的字節緩沖區”），和JEP 358 （“ 有用的NullPointerExceptions ”）。 這篇文章總結了針對JDK 14提出的這六個JEP。

JEP 345：針對G1的NUMA感知內存分配

JEP 345的簡潔“摘要”指出：“通過實現NUMA感知的內存分配來提高大型計算機上的G1性能 ?！?此JEP的兩個重要“非目標”表明，該JEP僅旨在向G1垃圾收集器添加NUMA（ 非統一內存訪問 ）支持，并且僅適用于Linux。 但是，JEP還指出，“由-XX:+UseParallelGC支持的并行收集器已經知道NUMA了很多年。”

JEP 361：開關表達式（標準）

JEP 361將開關表達式從其JEP 325的 “預覽”狀態移動到“標準”狀態。 在此過程中， JEP 354 （針對JDK 13 ）對預覽切換表達式功能進行了更改：“要從切換表達式生成值，將使用break語句來代替yield語句。 JEP 361的“歷史記錄”部分討論了JDK 12和JDK 13在預覽狀態下對開關表達式的支持，并解釋了為什么建議在JDK 14中將其用于標準狀態：“在JDK 13上的反饋表明，此功能現已準備就緒并在JDK 14中永久存在?！?

JEP 363：刪除并發標記掃描（CMS）垃圾收集器

JEP 363的簡潔“摘要”指出：“刪除并發標記掃描（CMS）垃圾收集器?！?JEP 291 （ JDK 9 ）已棄用了并發標記掃描 （ CMS ）垃圾收集器，該JEP旨在與JDK 14一起將其完全刪除 。

JEP 364：macOS上的ZGC / JEP 365：Windows上的ZGC

JEP 364和JEP 365的目標是分別將ZGC垃圾收集器“移植”到macOS和Windows操作系統。

JEP 364的“動機”部分指出：“盡管我們希望需要ZGC可伸縮性的用戶使用基于Linux的環境，但在部署應用程序之前，開發人員通常會使用Mac進行本地開發和測試。” 盡管JEP 365缺少明確的“動機”部分，但其動機可能類似于JEP 364的動機。

JEP 365的“非目標”部分指出：“支持Windows 10和版本早于1803的Windows Server并非目標，因為較早的版本缺少用于預留空間的API?！?

JEP 367：刪除Pack200工具和API

JEP 367的“摘要”部分以以下語句開頭：“刪除java.util.jar包中的pack200和unpack200工具以及Pack200 API ?！?不推薦使用時，這些工具和API的刪除是通過JEP 336在Java SE 11中發布的。

棄用 JEP 336和刪除 JEP 367的“動機”部分列出了棄用和刪除Pack200的三個原因，并得出以下結論：“總的來說，維護Pack200的成本是巨大的，并且超過了將其包含在Java中的好處。 SE和JDK?！?

JEP 336的“風險和假設”部分包含以下語句：“我們假定使用pack200收縮應用程序JAR的開發人員可以切換到jlink工具或jpackage工具，以優化的尺寸系數創建特定于應用程序的運行時?！?在r / java sub-reddit上討論了jlink和jpackage的適用性。

Java SE規范的影響

Iris Clark發布了這些JEP中的兩個具有Java SE范圍。 她寫道JEP 361 （開關表達式標準）和JEP 367 （刪除Pack200）“范圍為'SE'[并且]已被提議作為Java SE 14的目標?！?

結論

如果為JDK 14提議的所有六個JEP都針對JDK 14，那么將有九個與JDK 14相關聯的JEP。 我特別期待的兩個是使用JEP 361標準化開關表達式功能和使用JEP 358標準化更好的NPE消息 。

翻譯自: https://www.javacodegeeks.com/2019/11/six-more-jeps-proposed-for-jdk-14.html

jep290涉及jdk版本

總結

以上是生活随笔為你收集整理的jep290涉及jdk版本_针对JDK 14提议的另外六个JEP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。