JDK/Java 16 已于今年 3 月份正式 GA,这是一个短期维护版本,仅有 6 个月的技术支持。下一个版本 JDK/Java 17 计划于今年 9 月 14 日发布,这是一个长期支持(LTS)版本,预计 Oracle 将提供数年的扩展支持。
JDK 17 现在已经进入了第二个也是最后一个候选版本阶段(RC),目前最新版本是 Build 35。
按 InfoWorld 所述,OpenJDK JDK 17 的部分功能包括有:
- Context-specific 反序列化过滤器允许应用程序通过调用 JVM-wide filter factory 为每个序列化操作选择过滤器,来配置 context-specific 和 dynamically selected 的反序列化过滤器。
- 随着 always-strict 浮点语义的恢复,浮点运算将保持一致的严格;而不是同时具有严格的浮点语义 (
strictfp
) 和有着微妙出入的默认浮点语义。这就为语言和 VM 恢复了原始的浮点语义,与 Java Standard Edition 1.2 中引入严格和默认浮点模式之前的语义相匹配。 - 弃用 Security Manager,准备在未来版本中移除。追溯到 Java 1.0,Security Manager 一直是保护客户端 Java 代码的主要手段,很少用于保护服务器端代码。该提案的一个目标是评估是否需要新的 API 或机制来解决使用 Security Manager 的特定狭窄用例,例如阻塞
System::exit
。计划要求弃用 Security Manager 以与旧 Applet API 一起删除,该 API 也计划在 JDK 17 中弃用。 switch
模式匹配预览版扩展了 Java 中的模式语言,允许switch
表达式和语句可以针对多个模式进行测试,每个模式都有特定的操作。这使得复杂的面向数据的查询能够简洁而安全地表达。此功能的目标包括:通过使模式出现在案例标签中,来扩展switch
表达式和语句的表现力和应用,在需要时放宽switch
的 historical null-hostility,并引入两种模式:guarded patterns
,允许用任意的布尔表达式来完善模式匹配逻辑,以及parenthesized patterns
,解决了一些解析歧义。在 JDK 16 中,instanceof
运算符被扩展为采用类型模式并执行模式匹配。提议的适度扩展允许简化熟悉的 instanceof-and-cast 习语。- JDK 内部的强封装,除了
sun.misc.Unsafe
等关键的内部 API 外,用户将不再可能通过单个命令行选项来 relax 对内部元素的强封装,这在 JDK 9 到 JDK 16 中是可行的。该计划的目标包括提高 JDK 的安全性和可维护性,并鼓励开发人员从内部元素迁移到标准 API。 - 删除远程方法调用 (RMI) 激活机制,同时保留 RMI 的其余部分。RMI 激活机制已过时和废弃,在 JDK 15 中不推荐使用。
- 在外部函数和 memory API 引入了一个孵化器阶段,允许 Java 程序与 Java 运行时之外的代码和数据进行互操作。API 计划的目标包括易用性、性能、通用性和安全性。
- 与平台无关的矢量 API 作为孵化 API 集成到 JDK 16 中,将在 JDK 17 中再次孵化,提供一种机制来表达矢量计算,这些计算在运行时可靠地编译为支持的 CPU 架构上的最佳矢量指令。这比等效的标量计算获得了更好的性能。在 JDK 17 中,向量 API 已针对性能和实现进行了增强,包括在字节向量与布尔数组之间进行转换的增强功能。
- 密封类和接口限制哪些其他类或接口可以扩展或实现它们。该提案的目标包括允许类或接口的作者控制哪些代码负责实现它,提供比访问修饰符更具声明性的方式来限制超类的使用,并通过为模式的详尽分析提供基础来支持模式匹配的未来方向。
- 删除实验性 AOT 和 JIT 编译器,它们几乎没有使用,但需要大量维护工作。该计划要求维护 Java 级别的 JVM 编译器接口,以便开发人员可以继续使用外部构建的编译器版本进行 JIT 编译。
- 将 JDK 移植到 MacOS/AArch64 以响应 Apple 将其 Macintosh 计算机从 x64 转换到 AArch64 的计划。针对 MacOS/AArch64 的更改有可能破坏现有的 Linux/AArch64、Windows/AArch64 和 MacOS/x64 port,但这种风险可通过预集成测试来降低。
- 弃用 Applet API 以进行删除。这个 API 本质上是无关紧要的,因为所有 Web 浏览器供应商要么已经取消了对 Java 浏览器插件的支持,要么已经宣布了这样做的计划。Applet API 之前在 2017 年 9 月的 Java 9 中已被弃用,但并未删除。
- 用于 MacOS 的新渲染管道,使用 Apple Metal API 作为使用已弃用 OpenGL API 的现有管道的替代方案。该提议旨在为使用 MacOS Metal 框架的 Java 2D API 提供一条功能齐全的渲染管道,为苹果从未来版本的 MacOS 中删除 OpenGL API 做好准备。该管道旨在功能上与现有的 OpenGL 管道相当,在某些应用程序和基准测试中具有相同或更好的性能。将创建适合当前 Java 2D 模型的干净架构。管道将与 OpenGL 管道共存,直到被淘汰。本提案的目的并不是添加任何新的 Java 或 JDK API。
- 增强的伪随机数生成器将为伪随机数生成器(PRNG)提供新的接口类型和实现,包括可跳转的 PRNG 和额外的一类可拆分 PRNG 算法 (LXM)。新接口
RandomGenerator
将为所有现有的和新的 PRNG 提供统一的 API;将提供四个专门的 RandomGenerator 接口。该计划的动机是关注 Java 中伪随机数生成领域的多个改进领域。这项工作不需要提供许多其他 PRNG 算法的实现。但是已经添加了三种常用算法,这些算法已经广泛部署在其他编程语言环境中。该计划的目标包括:- 使在应用程序中交替使用各种 PRNG 算法变得更容易。
- 改进了对基于流的编程的支持,提供了 PRNG 对象流。
- 消除现有 PRNG 类中的代码重复。
- 保留类
java.util.Random
的现有行为。
JDK 17 等 LTS 版本每三年发布一次,上一个LTS 版本 JDK 11 于 2018 年 9 月发布。
详情查看: https://jdk.java.net/17/
下一节:根据 W3Techs 近日发布的报告,PHP 在 Web 服务器端的编程语言中仍拥有极高的占比,大约为 80%。