Java Development Kit 15是甲骨文公司发布 Java SE（标准版）的最新版本，它在6月11日进入缓降阶段，系列功能现在被冻结。JDK 15的亮点包括文本块、隐藏类、外部内存访问API以及密封类和记录的预览。
Java升级的下一个阶段是另一个缓降阶段，从现在起到8月20日有两个可选版本。预计9月15日正式上市。JDK15紧随3月17日发布的JDK14。甲骨文公司遵循标准Java六个月的发布计划，新版本每年发布两次。
第二个孵化器外部内存访问API，它可以使Java程序安全、高效地访问Java堆栈之外的外部内存。API应该能够对各种类型的外部内存进行操作，例如本机内存、持久内存和托管堆。许多Java程序访问外存，如Ignite和MapDB。API将有助于避免垃圾收集相关的成本和不可预测性，跨进程共享内存，并通过将文件映射到内存来序列化和反序列化内存内容。javaAPI目前还没有为访问外存提供令人满意的解决方案。但有了新的提议，即API不应该破坏JVM的安全性。这个功能在jdk14中经历了早期的孵化阶段，在jdk15中进行了改进。
密封类的预览。与接口一起，密封类限制了那些可以扩展或执行的其它类或接口。此特性的目标包括允许类或接口的作者控制由哪些代码负责实现它，并提供比访问修饰符更具声明性的方式来限制超类的使用，还有通过支持对模式的详尽分析来支持模式匹配的未来方向。
删除对Solaris/SPARC、Solaris/x64和Linux/SPARC端口的源代码和构建支持，而在JDK 14中不赞成删除这些端口，但可在将来的版本中删除它们。许多正在开发的项目和功能（如Valhalla、Loom和Panama）需要进行重大更改以适应CPU架构和操作系统特定代码。放弃对Solaris和SPARC端口的支持将使OpenJDK社区的贡献者加快开发新特性，从而推动平台向前发展。近年来，Solaris和SPARC都被Linux操作系统和Intel处理器所取代。
记录作为不可变数据的透明载体的类，在jdk14中作为早期预览发布之后，将被包含在jdk15的第二个预览版本中。该计划的目标包括设计一个面向对象构造来表达一个简单的值聚合。以协助程序员专注于不可变数据的建模，而非扩展性行为。自动实现数据驱动的方法，如equals和assessors，并保留Java中长期存在的原则，如名义类型和迁移兼容性。记录可以看作是名义元组。
基于爱德华曲线数字签名算法（EdDSA）的密码签名。EdDSA是一种现代的椭圆曲线方案，对比JDK中现有的签名方案更具有优势。EdDSA将仅在SunEC提供程序中执行。与其他签名方案相比，EdDSA具有更高的安全性和性能，因此受到人们的青睐；加密库中已经支持EdDSA，如OpenSSL和BoringSSL。
通过替换java.net.datagram.Socket和java.net.MulticastSocket APIs的实现以更简单和更现代的方式重新实现以前的DatagramSocket API。且易于调试和维护使用项目中当前正在探索的虚拟线程。新计划是JDK增强建议353的后续，该提议重新实现了遗留的Socket API。当前java.net.datagram.Socket和java.net.MulticastSocket的实现可以回溯到jdk1.0，那时IPv6还在开发中。因此，当前的MulticastSocket执行试图以难以维护的方式调节IPv4和IPv6。
默认情况下禁用偏向锁定并弃用所有相关的命令行选项。其目标是确定是否需要继续支持高代价维护，及偏向锁的遗留同步优化，该优化用于热点虚拟机，以减少竞争性锁定的开销。尽管某些Java应用程序可能会在禁用偏向锁定的情况下出现性能的回归，但是偏向锁的性能增益通常不如以前那么明显。instanceof匹配第二个预览模式，紧随JDK 14中之前的预览。模式匹配允许程序中的通用逻辑，主要是从对象中有条件地提取组件，以更简洁地表达。Haskell和C等语言因其简洁和安全而采用了模式匹配。
隐藏类，即不能被其他类字节码直接使用的类，倾向于借助框架使用，框架会在运行时生成类并通过反射间接使用它们。隐藏类可被定义为访问控制嵌套的成员，并且可以独立于其他类进行卸载。这项提议将提高JVM上所有语言的效率，方法是使用标准API定义不可发现且生命周期有限的隐藏类。
JDK内外的框架将能够动态生成这样的类，其可以定义隐藏类。许多构建在JVM上的语言都依赖于动态类生成来提高灵活性和效率。该建议的目标包括：允许框架将类定义为框架内无法发现的实现细节，因此它们不能被其他类链接，也不能通过反射发现；借助不可发现类，支持扩展访问控制嵌套；支持主动卸载不可发现类，以便框架可以根据需要灵活地定义多个类。另一个目标是反对非标准API，misc.Unsafe::defineAnonymousClass，目的是在将来的版本中不推荐删除。另外，Java语言不会因为这个提议而改变。Z Garbage Collector (ZGC)将由实验性功能发展为这个新议案下的产品。ZGC集成至2018年9月发布的JDK 11中，是一个可伸缩的低延迟垃圾收集器。ZGC是作为一种实验性的功能引入的，因为Java的开发人员认为，这种规模和复杂性的特性应该谨慎而逐步地引入。自那时起，改进了许多功能，包括并发类卸载、不提交未使用的内存、支持数据类共享到改进的NUMA感知和多线程堆预处理。另外，最大堆大小已从4TB增加到16TB。支持的平台包括Linux、Windows和MacOS。
在jdk14和jdk13中预览的文本块旨在简化Java程序编写任务，其可使跨越几行源代码的字符串变得容易表达，同时避免了常见情况下的转义序列。文本块是一个多行字符串文本，它避免了使用过多转义序列，并以可预测的方式自动格式化字符串，并在需要时为开发人员提供对格式的控制。文本块方案的目的是增强Java程序中表示用非Java语言编写字符串的可读性。另一个目标是支持字符串文本的迁移，以确保任何新的构造都可以将同一组字符串表示为字符串文本，解释相同的转义序列，并以与字符串文本相同的方式进行操作。OpenJDK开发人员希望添加转义序列来管理显式的空白和换行控制。Shenandoah low-pause-time垃圾收集器将成为产品的一个特性，并将退出实验阶段。一年前，它已经被集成到jdk12中。
2014年3月在jdk8中首次亮相的Nashorn被移除，由于其被GraalVM等技术淘汰。OpenJDK 15提议要求删除Nashorn APIs和用于调用Nashorn的jjs命令行工具。
弃用RMI激活机制，以方便将来删除。由于RMI激活机制是RMI中一个过时的功能，自java8以来一直作为可选项。RMI激活会持续地增加维护负担。而RMI的其他部分不会被弃用。jdk15的早期访问构建可以在java.jdk.net查看 JDK15将是一个短期特性发布版，根据Oracle六个月的发布cadence，它将支持6个月。下一个长期支持（LTS）版本将是JDK17，它将在2021年9月发布，它将获得数年的支持。目前的LTS版本是JDK 11，发布于2018年9月。
