Java Development Kit (JDK) 14 has entered the release candidate stage, the overall basic function has been determined. Planned standard Java upgrade with new features, such as JDK Flight Recorder stream of events, and switch expression pattern matching.
After JDK 14 plans to release the rhythm set six months in Java, 2020 March 17 officially released. JDK 14 for the function include:
- JFR a stream event API, JFR for continuous use processes and process data from the external application. JFR is a tool for collecting profiling and diagnostic data about the Java application is running in. Event stream recommend recording the same set of events non-flow situation and, if possible, spending less than one percent. Flow of events must coexist with disk-based and non-memory-based flow records. In this case, HotSpot VM using JFR issued more than 500 data points, of which the most data can be used only by analyzing the log files, making it easy to excite this proposal. Currently, users must start recording, stop recording, the contents of the dump to disk, and then parse the recording file. This profiling is very effective for applications, but not for monitoring purposes. Monitoring a usage example of the instrument panel is a dynamic update data. Create a record imposes overhead, such as copying data from a disk storage library to a separate log file. If there is a way to read data from the disk being recorded in the repository without creating a new log file, you can avoid a lot of overhead.
- NullPointerExceptions planned to improve by involving an accurate description of what variable is null to improve the availability of abnormal JVM generated. The author of the proposal hope to provide procedures for developers and support personnel premature termination of useful information, and more clearly the dynamic and static abnormalities associated with program code to improve understanding of the process through. One goal is to reduce developer confusion and concern 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处理器取代了其技术领域。