在发布前夕，我们不妨先一窥新版 JDK 的新特性：
第二个外部内存访问 API（孵化阶段），它将使 Java 程序安全高效地访问 Java 堆以外的外部存储器。该 API 应该能够在各种外部内存（如本机、持久和托管堆）上进行操作。许多 Java 程序访问外部存储器，如 lgnite 和 MapDB。API 有助于避免与垃圾回收相关的成本和不可预测性，跨进程共享内存以及通过将文件映射到内存，来序列化和取消序列化内存内容。Java API 目前无法提供令人满意的访问外部内存的解决方案。但是，随着新提案的提出，API 不应损害 JVM 的安全性。此功能正在 JDK 14 中进入较早的孵化器阶段，JDK 15 中提供了改进。
密封类的预览版。密封类与接口一起限制其他类或接口可以扩展或实现它们。此功能的目标包括允许类或接口的开发者控制负责实现该代码，提供比访问修饰符更具声明性的方式来限制超类的使用，以及通过支持详尽的内容来支持模式匹配的未来方向。
删除源代码并构建对 Solaris/SPARC、Solaris/x64 和 Linux/SPARC 端口的支持，这些端口在 JDK 14 中已弃用，目的是在将来的版本中删除它们。许多项目和功能在开发中，如 Valhalla、Loom 和 Panama 都需要对 CPU 架构和操作系统特定的代码进行重大更改。放弃对 Solaris 和 SPARC 端口的支持将使 OpenJDK 社区的贡献者能够加速开发新功能，从而推动平台向前发展。近年来，Solaris 和 SPARC 都已被 Linux 操作系统和英特尔处理器取代。
记录是充当不可变数据的透明载体的类，在 JDK 14 中作为早期预览版首次亮相后，将包含在 JDK 15 中的第二个预览版本中。该计划的目标包括设计一个面向对象的构造，该构造表示值的简单聚合，帮助程序员专注于对不可变数据建模，而不是可扩展行为，自动实现数据驱动方法（如等值器和评估器），以及保留长期存在的 Java 原则（如名义类型和迁移兼容性）。记录可视为名义元组。
基于爱德华兹曲线数字签名算法（EdDSA） 的加密签名。EdDSA 是一种现代椭圆曲线方案，与 JDK 中现有的签名方案相比具有优势。EdDSA 将仅在 SunEC 提供程序中实现。与其他签名方案相比，EdDSA 的安全性和性能有所提高，因此对其需求更为强烈，目前，它已在 OpenSSL 和 BoringSSL 等加密库中得到支持。
通过替换java.net.datagram 的基础实现，重新实现旧版 DatagramSocket API。Socket 和java.net.MulticastSocket API 具有更简单、更现代的实现方式，即：1. 易于调试和维护；2. 与 Project Loom 中正在探索的虚拟线程一起使用。新计划是 JDK 增强建议 353 的后续行动，该提案重新实现旧版 Socket API。java.net.datagram.Socket 和java.net.MulticastSocket 的当前实现可追溯到 JDK 1.0，而 IPv6 仍在开发中。因此，MulticastSocket 的当前实现尝试以难以维护的方式协调 IPv4 和 IPv6。
默认情况下，禁用偏向锁定，并弃用所有相关的命令行选项。该目的是确定是否需要继续支持昂贵、具有维护成本的偏向锁定的传统同步优化，该优化用于 HotSpot 虚拟机，以减少无可调整锁定的开销。尽管某些 Java 应用程序可能会看到禁用偏锁定时性能下降，但偏置锁定的性能提升通常不如以前明显。
继 JDK 14 中的前一个预览之后，第二个模式匹配预览。模式匹配允许程序中的通用逻辑（主要是从对象中的条件提取组件）可以更简洁地表达。Haskell 和 C# 等语言已采用模式匹配来实现简洁和安全性。
隐藏类。即不能由其他类的字节码直接使用的类，供在运行时生成类并通过反射间接使用它们的框架使用。隐藏类可以定义为访问控制嵌套的成员，并且可以独立于其他类进行卸载。该提案通过启用标准 API 来定义无法发现且具有有限生命周期的隐藏类，从而提高 JVM 上所有语言的效率。JDK 内外的框架将能够动态生成类，而这些类可以定义隐藏类。基于 JVM 的许多语言都依赖于动态类生成，以实现灵活性和效率。该提案的目标包括：允许框架将类定义为框架的不可发现的实现细节，以便其他类不能将其链接，也不能通过反射发现；支持使用不可发现类扩展访问控制嵌套；并支持主动卸载不可发现类，因此框架可以灵活地定义尽可能多的类。另一个目标是弃用非标准 APImisc.Unsafe::defineAnonymousClass，目的是在将来的版本中弃用。此外，Java 语言不会因此建议而更改。
根据提案，Z 垃圾收集器 （ZGC）将从实验版本过渡到产品中。ZGC 最初集成在2018 年 9 月的 JDK 11 中，是一个可扩展的低延迟垃圾回收器。ZGC 是作为实验功能引入的，因为 Java 开发人员认为，这种规模和复杂性的功能应该谨慎且逐步地引入。自 2018 年以来，ZGC 已增加了许多改进，从并发类卸载、取消使用未使用的内存、对类数据共享的支持到改进的 NUMA 感知。此外，最大堆大小从 4 TB 增加到 16 TB。支持的平台包括 Linux、Windows 和 MacOS。
文本块。这一功能在 JDK 14 和 JDK 13 中都已实现预览版。它跨越多行源代码，同时避免在常见情况下的转义序列，从而简化编写 Java 程序的任务。文本块是一个字符串文字，它避免了大多数转义序列，以可预测的方式自动格式化字符串，并根据需要为开发人员提供了对该格式的控制权。文本块建议的目标是提高 Java 程序中的字符串的可读性，这些字符串表示以非 Java 语言编写的代码。另一个目标是支持从字符串文本迁移，规定任何新构造都可以表达与字符串文本相同的字符串集，解释相同的转义序列，并且以与字符串文本相同的方式进行操作。OpenJDK 开发人员希望添加转义序列来管理显式空白和换行控件。
低暂停时间的垃圾收集器Shenandoah 将从实践阶段推向生产。一年前，该功能特性被加入了 JDK 12 中。
删除 Nashorn。该功能是 2014 年 3 月发布的 JDK 8 的新特性，但此后没多久就被诸如 GraalVM 等技术淘汰。根据提案，OpenJDK 15 建议要求删除Nashorn API 和用于调用 Nashorn 的 jjs 命令行工具。
弃用 RMI 激活机制，这也是为了将来为这一功能移除做准备。事实上，自 Java 8 以来，RMI 激活机制一直作为是可选项而非必选项，这也被视为是 RMI 中过时的部分。当下，RMI 的激活机制如果不弃用会造成维护负担。同时据了解，RMI 的其他部分暂时不会被弃用。
目前，JDK 15 的早期访问版本可以尝鲜：http://jdk.java.net/15/。继长期版本 JDK 11 之后，JDK 12/13/14以及即将发布的 JDK 15 都将是一个短期版本。而下一个长期支持 （LTS） 版本将是 JDK 17，该版本预计于 2021 年 9 月发布。
那么对于即将发布的 JDK 15，你会更新吗？