明年发布的 Java 版本，即 Java 26，增加了 AOT 对象缓存、向量 API、延迟常量以及编码加密对象的新特性。
JDK 26 是 Java 标准版计划于 2026 年 3 月 17 日推出的更新版本，截至目前已确定了九项新特性。此次发布计划中最新的特性包括 AOT 对象缓存、向量 API 的第十一次孵化、延迟常量的第二轮预览、加密对象编码的第二轮预览、结构化并发的第六轮预览，以及关于使用深度反射修改最终字段的警告。
虽然这些特性在 OpenJDK 的 JDK 26 页面上均未列出，但在官方的 JEP（JDK 增强提案）中，它们都被设定为 JDK 26 的特性。此前计划纳入 JDK 26 的三项特性包括：通过减少 G1 垃圾收集器（GC）中的同步来提高吞吐量、引入 HTTP/3 API，以及移除 Java Applet API。
JDK 26 是 Java 的短期发布版本，提供为期六个月的高级支持。在 JDK 26 之前，JDK 25 于 9 月 16 日发布，JDK 25 是长期支持（LTS）版本，提供数年的高级支持。
Ahead-of-Time Object Caching with Any GC
JEP 516: Ahead-of-Time Object Caching with Any GC，增强 AOT 缓存功能。
该功能让 HotSpot Java 虚拟机缩短启动和预热时间，使其可与任何垃圾收集器配合使用，包括低延迟的 Z 垃圾收集器（ZGC）。实现方式为，让缓存的 Java 对象能够从中立的、与垃圾收集器无关的格式按顺序加载到内存中，而不是以特定于垃圾收集器的格式直接映射到内存中。
目标如下：
- 让所有垃圾收集器都能与Project Leyden引入的 AOT 缓存顺畅配合。
- 将 AOT 缓存与垃圾收集器的实现细节和策略分离开来。
- 确保相较于之前的版本，使用 AOT 缓存不会对启动时间产生重大影响。
Vector API
JEP 529: Vector API (Eleventh Incubator)，向量 API（第十一个孵化器项目）。
引入一个 API 来表示向量计算，该 API 能在运行时可靠地编译为受支持 CPU 上的最优向量指令，从而实现优于等效标量计算的性能。
尚处于孵化阶段的向量 API 可追溯到 2021 年 3 月发布的 JDK 16。该 API 旨在做到清晰简洁、与平台无关，在 x64 和 AArch64 CPU 上实现可靠的编译和高性能，并具备适度的降级处理能力。向量 API 的长期目标是利用 Project Valhalla 对 Java 对象模型的改进。
Lazy Constants
JEP 526: Lazy Constants (Second Preview)，延迟常量（第二次预览）。
引入一个用于延迟常量的 API，延迟常量是存储不可修改数据的对象。JVM 将延迟常量视为真正的常量，这使得它能够实现与将字段声明为 final 时相同的性能优化。然而，与 final 字段相比，延迟常量在初始化时机方面提供了更大的灵活性。这是一个预览版 API。
PEM Encodings of Cryptographic Objects
JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)，加密对象的PEM编码（第二次预览）。
PEM （隐私增强邮件）编码的第二次预览需要一个 API，用于将表示加密密钥、证书和证书撤销列表的对象编码为 PEM 传输格式，并从该格式解码回对象。PEM API 在 JDK 25 中作为预览功能提出。第二次预览有许多变化，例如 PEMRecord 类现在名为 PEM，并且现在包括一个 decode() 方法，该方法返回解码后的 Base64 内容。此外，EncryptedPrivateKeyInfo 类的 encryptKey 方法现在名为 encrypt，并且现在接受 DEREncodable 对象而不是 PrivateKey 对象，从而可以对 KeyPair 和 PKCS8EncodedKeySpec 对象进行加密。
Structured Concurrency
JEP 525: Structured Concurrency (Sixth Preview)，结构化并发（第六次预览）。
Kotlin 开发者应该不陌生结构化并发。
结构化并发 API 将在不同线程中运行的相关任务组视为单个工作单元，从而简化了并发编程，进而简化了错误处理和取消操作，提高了可靠性，并增强了可观察性。其目标包括推广一种并发编程风格，这种风格能够消除因取消和关闭而产生的常见风险，如线程泄漏和取消延迟，以及提高并发代码的可观察性。
Make Final Mean Final
JEP 500: Prepare to Make Final Mean Final，让 final 名副其实。
关于使用深度反射来修改最终字段的新警告，旨在让开发者为未来的版本做好准备。未来版本将通过限制对最终字段的修改，默认情况下确保数据完整性，换句话说，就是让 final 名副其实。这将使 Java 程序更安全，并且可能运行得更快。应用开发者可以通过在必要的地方有选择地启用修改最终字段的功能，来避免当前的警告和未来的限制。
G1 GC
JEP 522: G1 GC: Improve Throughput by Reducing Synchronization，G1 垃圾回收器：通过减少同步来提高吞吐量。
G1 垃圾回收器提案旨在通过减少应用程序线程与垃圾回收器线程之间所需的同步量，提高使用 G1 垃圾回收器时的应用程序吞吐量和降低延迟。目标包括降低 G1 垃圾回收器的同步开销，减小为 G1 写屏障注入代码的规模，并且在不改变用户交互的情况下保持 G1 的整体架构。
G1 垃圾回收器提案指出，尽管 G1 作为 HotSpot JVM 的默认垃圾回收器，旨在平衡延迟和吞吐量，但与以吞吐量为导向的垃圾回收器（如 Parallel 和 Serial 收集器）相比，实现这种平衡有时会对应用程序性能产生不利影响：
与 Parallel 垃圾回收器相比，G1 与应用程序并发执行更多的工作，从而缩短了垃圾回收暂停的持续时间，进而改善了延迟情况。不可避免的是，这意味着应用程序线程必须与垃圾回收线程共享 CPU，并与它们进行协调。这种同步操作既降低了吞吐量，又增加了延迟。
HTTP/3 for the HTTP Client API
JEP 517: HTTP/3 for the HTTP Client API，支持 HTTP/3 的 HTTP Client API。
HTTP/3 提案要求让 Java 库和应用程序只需进行极少的代码更改，就能与 HTTP/3 服务器进行交互。目标包括更新 HTTP Client API，以发送和接收 HTTP/3 请求与响应；只需对 HTTP Client API 和 Java 应用程序代码进行微小更改；允许开发人员选择使用 HTTP/3，而非将协议版本从 HTTP/2 更改为 HTTP/3 。
HTTP/3 被视为用于 Web 的 HTTP（超文本传输协议）数据协议的一个主要版本。第 3 版是基于 IETF QUIC（快速 UDP 互联网连接）协议构建而成，该协议在其功能中着重于流量控制的流、低延迟连接建立、路径迁移以及安全性。
Remove the Applet API
JEP 504: Remove the Applet API，移除 Java Applet API。
移除如今被视为过时的 Java Applet API 也是 JDK 26 的目标之一。2021 年，在 JDK 17 中，该 API 已被标记为弃用并将予以移除。提案指出，由于近期发布的 JDK 版本和当下的网页浏览器均不支持 Applet，所以该 API 已经过时。提案称，没有理由保留这个无人使用且无法使用的 API。
其他更新
JDK 26 其他可能具备的特性包括在模式匹配 、instanceof 和 switch 中使用基本类型 （此特性已在 JDK 25 中进行预览）。JDK 25 中的一个实验性特性 ------ JFR CPU 时间分析功能，也有可能会纳入 JDK 26 中。还有一种可能性是借助 jcmd 工具进行事后故障分析，这将扩展 jcmd 工具的功能，使其能够用于诊断崩溃的 JVM。