JDK14都要问世了，你还在用JDK8吗

Java开发工具包（JDK）14已进入发布候选阶段，总体功能基本已确定。计划中的标准Java升级将具有新功能，例如JDK Flight Recorder事件流，模式匹配和开关表达式。

JDK 14计划在Java设定六个月的发布节奏之后，于2020年3月17 日正式发布。针对JDK 14的功能包括：

• JFR事件流 提供一个API，用于持续使用来自流程内和流程外应用程序的JFR数据。JFR是用于收集有关正在运行的Java应用程序的概要分析和诊断数据的工具。事件流建议记录与非流情况相同的事件集，并且如果可能，开销小于百分之一。事件流必须与基于磁盘和基于内存的非流记录共存。在这种情况下，HotSpot VM使用JFR发出500个以上的数据点，而其中的大多数数据仅可通过分析日志文件来使用，因此很容易激发这种提议。当前，用户必须开始录制，停止录制，将内容转储到磁盘，然后解析录制文件。这对于应用程序概要分析非常有效，但不适用于监视目的。监控使用情况的一个示例是显示动态更新数据的仪表板。创建记录会产生开销，例如将数据从磁盘存储库复制到单独的记录文件。如果有一种方法可以在不创建新记录文件的情况下从磁盘存储库读取正在记录的数据，则可以避免很多开销。
• 计划进行的改进 NullPointerExceptions涉及通过准确描述哪个变量为null来提高JVM生成的异常的可用性。该提案的作者希望为开发人员和支持人员提供有关程序过早终止的有用信息，并通过更清楚地将动态异常与静态程序代码相关联来提高对程序的理解。一个目标是减少开发人员的困惑和担忧NullPointerExceptions。
• 非易失性映射的字节缓冲区将添加新的特定于JDK的文件映射模式，该模式允许使用FileChannel API创建MappedByteBuffer引用非易失性内存（NVM）的实例。NVM使程序员可以跨程序运行来构建和更新程序状态，而不会产生输入和输出操作通常需要的大量复制或翻译成本。这对于交易程序尤其重要。因此，此JDK增强建议的主要目标是确保客户端可以连贯且有效地从Java程序访问和更新NVM。第二个目标是使用在class中定义的受限制的JDK内部API来实现此提交行为Unsafe，因此除其他类外，它可以重用它。MappedByteBuffer可能需要提交给NVM。另一个目标是允许现有API跟踪在NVM上映射的缓冲区，以进行监视和管理。目标OS / CPU平台包括Linux / x64和Linux / AArch64。
• 开关表达式通过扩展switch使其可以用作语句或表达式而简化了编码 。在JDK 12和JDK 13中都进行预览之后，开关表达式有望成为JDK 14的永久功能。开关表达式还为使用模式匹配做好了准备switch。模式匹配使开发人员可以更简洁，安全地从对象中有条件地提取组件。
• G1垃圾回收器的NUMA感知内存分配，旨在提高大型计算机上的G1性能。
• 删除并发标记扫描（CMS）垃圾收集器，该垃圾收集器先前已弃用并计划删除。CMS的后继者包括ZGC和Shenandoah。
• 将ZGC移植到MacOS。到目前为止，仅Linux才支持它。
• 删除java.util.jar软件包中的pack200和unpack200工具以及Pack200 API 。所有这些在Java SE 11中已弃用，目的是将来删除它们。Pack200是JAR文件的压缩方案。
• 记录，它将提供一种紧凑的语法来声明为浅层不可变数据的透明持有者的类。该提案指出，声明浅不可改变的，行为良好的名义数据集合应该简单明了。
• 一种打包工具，处于开发的孵化阶段，用于打包自包含的Java应用程序。该工具将基于JavaFX javapackager。此类工具已包含在Java中，但作为删除JavaFX的一部分从JDK 11中删除。
• 通过为 操作员提供模式匹配来增强语言instanceof。这将是JDK 14中的预览功能。模式匹配可以更简洁和安全地表示程序中的通用逻辑，主要是从对象中有条件地提取组件。
• 文本块的第二个预览，这是一种多行字符串文字，它避免了大多数转义序列的需要，并以可预测的方式自动格式化字符串。文本块将在需要时使开发人员可以控制格式，简化Java程序的编写，并增强字符串的可读性。文本块在JDK 13中进行了预览；JDK 14迭代将添加转义序列以管理显式空白和换行控制。
• 不赞成使用Parallel Scavenge和Serial Old垃圾收集算法的组合。Java维护者认为这种组合很少使用，但需要大量维护。
• 将ZGC（Z垃圾收集器）移植 到Windows。在恢复到提议的目标列表之后，此功能再次移至正式目标列表。
• 外部存储器访问API，引入了Java程序的API，可以安全有效地访问Java堆外部的外部存储器。该API应该可以替代Java程序访问内存（包括nio.ByteBuffer和）的主要途径sun.misc.Unsafe。新的API应该能够在各种类型的内存上运行，包括本机，持久性内存和托管堆。API不可能破坏JVM的安全性。内存释放应在源代码中明确。该API有望帮助开发本机互操作支持，这是巴拿马项目的目标。
• 弃用Solaris / Sparc，Solaris / x64和Linux / Sparc端口，以在将来的发行版中将其删除。放弃对这些端口的支持将使OpenJDK贡献者能够加速新功能的开发。尽管Solaris和Sparc是Java最初的创建者Sun Microsystems的关键技术，但近年来，它们已被Linux OS和Intel处理器取代了其技术领域。