JFR 事件流 为持续使用来自进程内和进程外应用程序的 JFR 数据提供 API。JFR 是一种工具,用于在 Java 应用程序和 JVM 运行时收集有关它们的分析和诊断数据。事件流提议记录与非流情况相同的事件集,如果可能的话,开销小于 1%。事件流必须与基于磁盘和基于内存的非流记录共存。推动这个提议的情况是 HotSpot VM 使用 JFR 发出超过 500 个数据点,其中大部分只能通过解析日志文件才能获得。目前,用户必须开始录制,停止录制,将内容转储到磁盘,然后解析录制文件。这适用于应用程序分析,但不适用于监控目的。监控使用情况的一个示例是显示数据动态更新的仪表板。创建记录会产生开销,例如将数据从磁盘存储库复制到单独的记录文件。如果有一种方法可以在不创建新记录文件的情况下从磁盘存储库中读取正在记录的数据,则可以避免大部分开销。
计划中的改进 NullPointerExceptions
涉及通过准确描述哪个变量为空来提高 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 表达式通过扩展来简化编码, switch
以便它可以用作语句或表达式。在 JDK 12 和 JDK 13 中预览之后,Switch 表达式有望成为 JDK 14 中的永久特性。Switch 表达式还准备在switch
. 模式匹配允许开发人员更简洁、更安全地有条件地从对象中提取组件。
G1 垃圾收集器的 NUMA 感知内存分配,旨在提高大型机器上的 G1 性能。
删除 Concurrent Mark Sweep (CMS) 垃圾收集器,之前已弃用并计划将其删除。CMS 的继任者已经出现,包括 ZGC 和Shenandoah。
将 ZGC 移植到 MacOS。到目前为止,它仅在 Linux 上受支持。
删除包中的 pack200 和 unpack200 工具以及 Pack200 API java.util.jar
。这些都在 Java SE 11 中被弃用,目的是在将来删除它们。Pack200 是 JAR 文件的压缩方案。
Records,它将提供一种紧凑的语法来声明作为浅不可变数据的透明持有者的类。记录使创建本质上是数据载体的类变得容易,而无需编写大量样板。该提案指出,声明浅不可变、行为良好、名义数据聚合应该简单而简洁。
一种打包工具,处于开发的孵化器阶段,用于打包自包含的 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 有望帮助开发本机互操作支持,这是Project Panama的目标。
弃用 Solaris/Sparc、Solaris/x64 和 Linux/Sparc 端口,打算在将来的版本中将其删除。放弃对这些端口的支持将使 OpenJDK 贡献者能够加速新功能的开发。尽管 Solaris 和 Sparc 是 Java 的最初创建者 Sun Microsystems 的关键技术,但近年来它们在技术领域已被 Linux 操作系统和英特尔处理器所取代。