Oracle 的 Java 平台首席架构师 Mark Reinhold 宣布 JDK 24 已处于 Rampdown 第二阶段，这意味着它的功能被冻结了，但现有 JEP（Java 增强提案）后期可能会在“极高”的通过门槛下得到更新。
JDK 24 将于 3 月 18 日发布。它不是长期支持（LTS）版本；下一个 LTS 版本是 JDK 25，预计于 9 月 16 日发布。Reinhold 上周在 OpenJDK 邮件列表中宣布了这一消息。JDK 24 包含 24 个 JEP，其中两个是实验性的，还有八个处于不同的预览阶段。值得注意的是，此版本删除了对 Windows 32 位 x86 的支持。JEP 479 指出，为了简化 JDK 的构建和测试基础架构，所有针对 Windows 32 位 x86 的测试和开发工作都将停止。其他 32 位平台（如 ARM32）仍将受支持，但 Linux 32 位 x86 端口将被弃用，计划在 JDK 25 中删除。
JDK 24 在使用 Java 原生接口（JNI）时引入了警告，JNI 是调用原生代码（例如用 C 编写的库）的长期方法。这里的想法不是弃用 JNI（尽管有一个新的外部函数和内存（FFM）API），而是为 JNI 和 FFM API 提供一致级别的警告。最终目标是希望调用原生代码的开发人员必须“在启动时明确启用 JNI 和 FFM API”，因为 Java 和原生代码之间的任何交互都是有风险的。
JEP 498 在第一次调用 sun.misc.Unsafe 命名空间中的任何内存访问方法时会发出警告。这些方法已被弃用，并将在未来版本中删除，从 JDK 26 开始，只要使用这些方法就会抛出异常。开发人员需要迁移到 FFM API 和 VarHandle API 中的标准 API。
新的性能特性 JEP 483 通过预先加载类来缩短启动时间。应用程序运行一次后会监视和缓存类，以便在下次运行时立即使用它们。完整的提案值得一读（https://openjdk.org/jeps/483）；缓存提案的历史可以追溯到 2004 年。根据该提案，使用此特性时，Spring PetClinic 示例的启动速度提高了 42%。
Java 历史的另一段回响出现在 JEP 486 中，它永久禁用了安全管理器。这是 Java 从第一个版本开始的一个特性，默认情况下将所有代码视为不受信任。问题是这个级别的沙盒代码太复杂了，这意味着很少有应用程序会使用它。之前的一个相关 JEP 指出，即使使用具有适用策略文件的框架（例如 Tomcat），“开发人员……仍然面临着几乎无法克服的挑战，即弄清楚他们自己的代码和他们使用的库所需的权限。”
安全管理器默认处于禁用状态，但即使启用它的可能性也会给 JDK 带来开销，从而“给 Java 平台库带来极大的复杂性”。现在这一负担被解除了。
量子计算带来了加密容易被破解的风险。JEP 496 和 497 为密钥封装和数字签名算法引入了抗量子模块。
新特性的完整列表可在此处（https://openjdk.org/projects/jdk/24/）找到。
原文链接：
https://devclass.com/2025/01/20/java-24-feature-frozen-as-it-enters-rampdown-phase-two/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
