JDK 24 是自 JDK 21 以来的第三个非长期支持版本。甲骨文公司 Java 平台组首席架构师 Mark Reinhold 宣布，JDK 24 已进入首个候选发布阶段。2024 年 12 月初，主线源代码仓库分支到 JDK 稳定版本仓库（Rampdown 第一阶段），这确定了 JDK 24 的功能集。对于关键漏洞，比如回归问题或严重的功能缺陷，可能会进行修复，但必须通过修复请求流程获得批准。按照发布计划，JDK 24 将于 2025 年 3 月 18 日正式发布 。以 JEP（Java 增强提案）形式呈现的最终 24 项新特性，可分为五大类：核心 Java 库、Java 语言规范、安全库、HotSpot 和 Java 工具。
核心 Java 库（7 项新特性）：
JEP 472：为限制 JNI 的使用做准备；
JEP 484：类文件 API；
JEP 485：流收集器；
JEP 487：作用域值（第四次预览）；
JEP 489：向量 API（第九次孵化）；
JEP 498：使用 sun.misc.Unsafe 中的内存访问方法时发出警告；
JEP 499：结构化并发（第四次预览）。
Java 语言规范（4 项新特性）：
JEP 488：模式、instanceof 和 switch 中的原始类型（第二次预览）；
JEP 492：灵活的构造函数体（第三次预览）；
JEP 494：模块导入声明（第二次预览）；
JEP 495：简单源文件和实例主方法（第四次预览）。
安全库（4 项新特性）：
JEP 478：密钥派生函数 API（预览）；
JEP 486：永久禁用安全管理器；J
EP 496：基于模块格的抗量子密钥封装机制；
JEP 497：基于模块格的抗量子数字签名算法。
HotSpot（8 项新特性）：
JEP 404：分代 Shenandoah（实验性）；
JEP 450：紧凑对象头（实验性）；
JEP 475：G1 的后期屏障扩展；
JEP 479：移除 Windows 32 位 x86 端口；
JEP 483：提前类加载和链接；
JEP 490：ZGC：移除非分代模式；
JEP 491：无需固定即可同步虚拟线程；
JEP 501：弃用 32 位 x86 端口以便后续移除。
Java 工具（1 项新特性）：
JEP 493：不使用 JMODs 链接运行时镜像。
我们来审视其中一些新特性，并了解它们在主要 Java 项目（Amber、Loom、Panama、Valhalla 和 Leyden）中的归属。这些项目旨在孵化一系列组件，最终通过精心策划的合并纳入 JDK。
JEP 495：简单源文件和实例主方法（第四次预览），在经过前三轮预览后，此次发布第四次预览且内容无变化（仅第二次更改了名称）。此前三轮预览分别是：JDK 23 中的 JEP 477“隐式声明类和实例主方法（第三次预览）”；JDK 22 中的 JEP 463“隐式声明类和实例主方法（第二次预览）”；JDK 21 中的 JEP 445“匿名类和实例主方法（预览）”。该特性旨在“改进 Java 语言，让初学者编写第一个程序时，无需理解为大型程序设计的语言特性”。这一 JEP 提案推进了甲骨文公司 Java 语言架构师 Brian Goetz2022 年 9 月发表的博客文章《 Paving the on-ramp》。甲骨文公司技术人员咨询成员 Gavin Bierman 已发布规范文档初稿，供 Java 社区审核。更多关于 JEP 445 的详细信息，可查看[InfoQ 新闻报道](https://www.infoq.com/news/2025/02/java-24-so-far/)。
JEP 487：作用域值（第四次预览），原名为“扩展本地变量（孵化）”。经过一轮孵化和三轮预览后，此次推出第四次预览且有一处变动。此前的预览版本分别是：JDK 23 中的 JEP 481“作用域值（第三次预览）”；JDK 22 中的 JEP 464“作用域值（第二次预览）”；JDK 21 中的 JEP 446“作用域值（预览）”；JDK 20 中的 JEP 429“作用域值（孵化）”。该特性支持在线程内部和线程之间共享不可变数据，与线程局部变量相比更具优势，尤其在使用大量虚拟线程时。与上一版预览相比，唯一的变动是从`ScopedValue`类中移除了`callWhere()`和`runWhere()`方法，以使 API 更加流畅。通过`ScopedValue.Carrier`类中定义的`call()`和`run()`方法，可实现使用一个或多个绑定的作用域值的功能。
在完成评审后，JEP 489：向量 API（第九次孵化）根据前八轮孵化的反馈意见进行了改进。此前的孵化版本分别是：JDK 23 中的 JEP 469“向量 API（第八次孵化）”；JDK 22 中的 JEP 460“向量 API（第七次孵化）”；JDK 21 中的 JEP 448“向量 API（第六次孵化）”；JDK 20 中的 JEP 438“向量 API（第五次孵化）”；JDK 19 中的 JEP 426“向量 API（第四次孵化）”；JDK 18 中的 JEP 417“向量 API（第三次孵化）”；JDK 17 中的 JEP 414“向量 API（第二次孵化）”；JDK 16 中作为孵化模块发布的 JEP 338“向量 API（孵化）”。原本计划复用最初的孵化状态进行重新孵化，最终决定继续按顺序编号。向量 API 将持续处于孵化阶段，直到 Valhalla 项目 的必要特性作为预览特性推出。届时，向量 API 团队将对向量 API 及其实现进行调整以使用这些特性，并将向量 API 从孵化阶段推进到预览阶段。
JEP 483 提前类加载和链接旨在“通过让应用程序的类在 HotSpot Java 虚拟机启动时，以加载和链接状态即时可用，从而缩短启动时间”。这可以通过在一次运行过程中监控应用程序，并将所有类的加载和链接形式存储在缓存中，以供后续运行使用来实现。该特性将为未来缩短启动时间和预热时间奠定基础。
JEP 497 基于模块格的抗量子数字签名算法旨在“通过提供符合 FIPS 204 标准的基于模块格的抗量子数字签名算法（ML-DSA）实现，增强 Java 应用程序的安全性”。这将通过实现 Java 的`KeyPairGenerator`、`Signature`和`KeyFactory`类来达成。
受 Lilliput 项目 启发，JEP 450 紧凑对象头（实验性）提议“在 64 位架构下，将 HotSpot JVM 中对象头的大小从 96 到 128 位缩减至 64 位”。由于该特性被视为实验性的，默认处于禁用状态，若开发者启用可能会导致意外后果。更多关于 JEP 450 的详细信息，可查看 InfoQ 新闻报道(https://www.infoq.com/news/2025/02/java-24-so-far/)。
JEP 404 分代 Shenandoah（实验性）提议提供一种实验性的分代模式，同时不影响非分代的 Shenandoah 垃圾回收器，目标是在未来的 JDK 版本中将分代模式设为默认选项。该 JEP 最初计划用于 JDK 21，但由于“评审过程中发现的风险，以及对如此大量代码贡献进行全面评审的时间不足”，最终从 JDK 21 的最终特性集中移除。当时，Shenandoah 团队决定将目标设定为未来的 JDK 版本，以“尽可能提供最佳的分代 Shenandoah”。#### JDK 25
JDK 25 计划于 2025 年 9 月发布正式版，目前尚无针对 JDK 25 的 JEP 提案。不过，基于一些 JEP 候选提案和草案，尤其是已提交的那些，我们可以推测哪些 JEP 有可能被纳入 JDK 25。甲骨文公司技术人员咨询成员 Gavin Bierman 在给 Java 社区的一封邮件中宣布，他计划在 2025 年 9 月 JDK 25 发布时，敲定 JEP 495“简单源文件和实例主方法（第四次预览）”中所谓的“入门匝道（on-ramp）”特性。截至目前，相关草案尚未创建，但预计很快会有变动。
JEP 502“稳定值（预览）”，原名为“计算常量（预览）”，引入了计算常量的概念，即最多初始化一次的不可变值持有者。它兼具`final`字段的性能和安全优势，同时在初始化时机上更具灵活性。
JEP 草案 8340343“结构化并发（第五次预览）”提议进行第五次预览，对 API 做出几处修改，以从前四轮预览中获取更多反馈。此前的预览版本分别是：即将在 JDK 24 正式版中发布的 JEP 499“结构化并发（第四次预览）”；JDK 23 中的 JEP 480“结构化并发（第三次预览）”；JDK 22 中的 JEP 462“结构化并发（第二次预览）”；JDK 21 中的 JEP 453“结构化并发（预览）”。该特性引入结构化并发，将“在不同线程中运行的相关任务组视为单个工作单元，从而简化错误处理和取消操作，提高可靠性并增强可观测性”，进而简化并发编程。其中一项 API 修改提议是，通过静态工厂方法而非公共构造函数来打开`StructuredTaskScope`接口。
JEP 草案 8326035“CDS 对象流”提议在 Z 垃圾回收器（ZGC）中为类数据共享（CDS）添加对象归档机制，并采用统一的 CDS 对象归档格式和加载器。该特性将把 GC 的实现细节和策略与 CDS 归档对象流机制分开。
JEP 草案 8300911“PEM API（预览）”引入了一种简单直观的 API，用于对隐私增强邮件（PEM）格式进行编码和解码，描述最多可更改一次的值持有者。PEM 格式将用于存储和发送加密密钥及证书。
JEP 草案 8291976“在 HttpClient 中支持 HTTP/3” 提议更新 JDK 11 中发布的 JEP 321“HTTP 客户端”，以支持 HTTP/3 协议。这将使应用程序和库能够与 HTTP/3 服务器交互，并通过最少的代码更改获得 HTTP/3 带来的优势。我们预计甲骨文公司很快就会确定针对 JDK 25 的 JEP。
Michael Redlich，在过去 25 年里，Michael Redlich 始终是 Java 社区的活跃成员。2001 年，他创立了花园州 Java 用户组（前身为 ACGNJ Java 用户组），这个用户组至今仍在持续运营。
从 2016 年开始，Mike（Michael 的昵称）担任 InfoQ 的 Java 社区新闻编辑。在此期间，他每月撰写新闻报道，进行技术内容创作，还参与技术评审工作，为社区贡献颇丰。他曾在诸多重要场合发表演讲，比如甲骨文 Code One 大会、企业新兴技术大会、Trenton 计算机节（TCF）、TCF IT 专业人员大会，以及众多 Java 用户组活动。
在技术规范制定领域，Mike 是 Jakarta NoSQL 和 Jakarta Data 规范的贡献者，积极推动相关技术的发展。同时，他还参与了 Jakarta EE 大使领导委员会，为该技术生态的发展出谋划策。2023 年 4 月，他荣获 Java Champion 称号，这无疑是对他在 Java 领域卓越贡献的高度认可。
Mike 在新泽西州克林顿市的埃克森美孚技术与工程公司工作了长达 33 年半之久，最近刚刚退休。在那里，他积累了丰富的科学实验室和网络应用程序定制化开发经验。此前，他还在 Ai-Logix 公司（现 AudioCodes）担任技术支持工程师，不仅为客户提供专业的技术支持，还负责开发电话应用程序。
原文链接：
https://www.infoq.com/news/2025/02/java-24-so-far/
本文由 InfoQ 独家翻译，未经授权不得转载。