JDK/Java 17 可能带来什么新特性？

Posted 2021-09-18 Java技术栈

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了JDK/Java 17 可能带来什么新特性？相关的知识，希望对你有一定的参考价值。

点击关注公众号，Java干货及时送达

文 | 白开水

出品 | OSC开源社区（ID：oschina2013）

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的现有行为。