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子reddit上讨论了jlink和jpackage的适用性。

Java SE规范的影响

Iris Clark发布了这些JEP中的两个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