JDK 17 - Java 17 的新特性速览

JEP 415：特定于上下文的反序列化过滤器

允许应用程序使用 JVM 范围的过滤器工厂配置特定于上下文和动态选择的反序列化过滤器，该工厂用于为每个反序列化操作选择一个过滤器。

动机：

• 不可信数据的反序列化是一项具有内在风险的操作，因为在许多情况下传入数据流的内容是通过未知或未经身份验证的客户端获取的。

• 防止序列化攻击的关键是禁止任意类的实例被反序列化，从而直接或间接地阻止其方法的执行。

• 攻击者可以通过仔细构造流来运行任何恶意的类中的代码。如果对象构造涉及更改状态或触发其他操作的副作用，则应用程序对象、库对象和 Java 运行时的完整性可能会受到损害。

JEP 414：Vector API （第二个孵化器）

引入一个与平台无关的矢量 API，它首先集成到 JDK 16 中，并将在 JDK 17 中再次孵化，以表达矢量计算，这些计算在运行时可靠地编译为支持的 CPU 架构上的最佳矢量指令，性能优于等效标量计算。

JDK 17 中的向量 API 已针对性能和实现进行了改进，包括在字节向量与布尔数组之间进行转换的增强功能。

目标：

• 清晰简洁的 API： API 应该能够以清晰简洁的方式表达各种向量计算。

• 平台不可知： API 应该独立于 CPU 架构，允许在支持向量指令的各种架构上实现。

• 在 x64 和 AArch64 架构上可靠的运行时编译和性能

• 优雅降级：如果无法将向量计算有效地编译为向量指令，则会发出警告。

JEP 412：外部函数和内存 API （孵化器）

引入一个 API，通过有效调用外部函数（即 JVM 外部的代码）和安全地访问外部内存（即不由 JVM 处理的内存），允许 Java 程序调用本地库和处理本地数据而没有 JNI 的风险.

在这个 JEP 提案中，是早期两个孵化 API 的演变：外部内存访问 API 和外部链接器 API。以前在 Java 14、15 和 Java 16 中针对的

目标：

• 易用性：用 Java 本机接口 (JNI) 替换卓越的纯 Java 开发模型。

• 性能：与现有 API（如 JNI 或 sun.misc.Unsafe）相似的性能，如果不是更好的话。表现。

• 常规：提供了在各种类型的外部内存（例如，本机内存、持久内存和堆内存）上工作的方法，并随着时间的推移适应其他平台（例如，x86 32 位）和用 C 以外的语言编写的外部函数（例如，C++、FORTAN）。

• 安全：仅当应用程序开发人员或最终用户明确选择加入时，才停用默认的不安全操作。

JEP 411：弃用安全管理器以进行删除

从 Java 1.0 开始，就有了一个安全管理器。然而，多年来它很少被使用。为了推动 Java 向前发展，安全管理器已在 Java 17 中被弃用，并将在未来版本中与旧 Applet API (JEP 398) 一起删除。

目标：

• 为开发人员在 Java 的未来版本中移除安全管理器做好准备。

• 如果用户的 Java 程序依赖于安全管理器，则发出警报。

• 评估是否需要新的 API 或机制来修复使用安全管理器的独特、有限的用例，例如阻塞 System::exit。

JEP 410：删除实验性 AOT 和 JIT 编译器

删除实验性的基于 Java 的提前 (AOT) 和即时 (JIT) 编译器，因为使用有限，维护它所需的工作量很重要。

即使保留了实验性的 Java 级 JVM 编译器接口 (JVMCI)，这样开发人员也可以继续使用外部构建的编译器版本，并使用 Graal 编译器 ( GraalVM )进行 JIT 编译。

动机：

作为实验性功能，JDK 9 已与提前编译（jaotc 工具）集成。对于 AOT 编译，jaotc 使用 Java 编写的 Graal 编译器。由于这些实验特性尚未使用，因此需要付出相当大的努力来维护和改进它们。Oracle 发布的 JDK 16 版本没有这些功能，也没有人抱怨。

JEP 409：密封类

密封类被提议并作为

JDK 16 中的第二个预览功能。

使用密封类和接口增强 Java 编程语言。密封类和接口限制其他类或接口可以扩展或实现。

目标：

• 使类或接口作者能够控制要实现它的代码。

• 提供比访问修饰符更具声明性的方法来限制超类的使用。

• 以彻底检查趋势的基础支持未来的模式匹配方向。

细化：

• 在 JLS 中，描述了上下文关键字的定义，它取代了之前对受限标识符和受限关键字的定义。

• 引入密封的、非密封的字符序列，并允许它们作为上下文关键字。

• 与匿名类和 lambda 表达式一样，在决定密封类或密封接口的隐式声明的允许子类时，局部类可能不是密封类子类。

一个类可以通过使用 Sealed 修饰符来密封 -允许它的声明。在任何extends 和 implements 子句之后，permit子句指定允许/允许扩展密封类的类。

package com.techgeeknext.example.species;public sealed class Animalpermits Dog, Monkey, Leopard {...}

package com.techgeeknext.example.species;public sealed class Animalcom.techgeeknext.example.species.canis.Dog,com.techgeeknext.example.species.macaca.Monkey,com.techgeeknext.example.species.rana.Leopard{....}

JEP 407：删除 RMI 激活

将删除远程方法调用 (RMI) 激活机制，但应保留 RMI 的其余部分。RMI 激活机制已变得多余，不再使用。Java SE 15 中的 JEP 385 弃用了它并建议将其删除。

JEP 406：开关模式匹配（预览）

switch 的模式匹配扩展了 Java 的模式语言，允许针对各种模式验证 switch 表达式和语句，每个模式都有不同的操作。这使得以简单和安全的方式表达复杂的面向数据的查询成为可能。

JDK 16 中的 instanceof 运算符已扩展为接受类型模式并执行模式匹配。提议的适度扩展简化了众所周知的 instanceof-and-cast 习语。

目标：

• 允许模式出现在 case 标签中增加了 switch 短语和语句的表现力和适用性。

• 如果需要，让历史转折点的零敌意放松。

• 将引入两种新模式：

1. 保护模式：使用任意布尔表达式来优化模式匹配逻辑。

2. 带括号的模式：清除解析歧义。

• 确保所有现有的 switch 表达式和语句都使用相同的语义进行编译，并在不做任何修改的情况下执行它们。

JEP 403：强封装 JDK 内部

强烈封装了 JDK 的所有内部元素，除了关键的内部 API，如 sun.misc.Unsafe.^A Unsafe。不再可能像从 JDK 9 到 JDK 16 那样，使用单个命令行选项来放松对内部部件的严格封装。

JEP 398：弃用 Applet API 以进行删除

Applet API 实际上是无用的，因为所有 Web 浏览器供应商都已删除或透露计划放弃对 Java 浏览器插件的支持。虽然 Applet API 在 Java 9 中已被弃用，但之前并未将其删除。

JEP 391：macOS/AArch64 端口

将 JDK 移植到新架构 macOS/AArch64 期待未来需求

动机：

• Apple 决定在其 Macintosh 计算机上从 x64 迁移到 AArch64。对于 Linux，AArch64 版本的 Java 已经可用，Windows 端口上的开发目前正在进行中。

• 由于程序二进制接口和保留处理器寄存器的集合等低级约定的差异，Java 开发人员计划通过使用条件编译来重用来自这些端口的现有 AArch64 代码，这是 JDK 端口中的标准。

• MacOS/AArch64 的更改有可能拆分当前的 Linux/AArch64、Windows/AArch64 和 MacOS/x64 端口，尽管可以通过预集成测试来减轻这种可能性。

JEP 382：新的 macOS 渲染管线

需要使用新的 Apple Metal 框架为 macOS 提供新的 Java 2D 渲染管道。与今天一样，Java 2D 完全依赖于 OpenGL。虽然 Apple 在 macOS 10.14 中弃用了 OpenGL 渲染库，但 Metal 框架取代了 OpenGL 渲染库。

目标：

• 为基于 macOS Metal 框架的 Java 2D API 提供功能齐全的渲染管道。

• 在选择的实际应用程序和基准测试中，提供与 OpenGL 管道相当或更好的性能。

• 与 OpenGL 管线共存，直至停产。

JEP 356：增强型伪随机数生成器

引入了伪随机数生成器 (PRNG) 的新接口和实现，其中包括可跳转 PRNG 和一类新的可拆分 PRNG 算法 (LXM)。

推动该计划的重点是 Java 伪随机数生成领域的多个改进领域。RandomGenerator 是一个现代接口，将为所有当前和新的 PRNG 提供统一的 API，以及四个专门的 RandomGenerator 接口。

目标：

• 使在不同的应用程序中使用不同的 PRNG 算法变得更简单。

• 通过提供 PRNG 对象的流，您可以更好地支持基于流的编程。

• 从当前 PRNG 组中删除冗余代码。

• 尽可能维护 java.util.Random 类的动作。

JEP 306：恢复始终严格的浮点语义

与其同时拥有严格的浮点语义 (strictfp) 和显着不同的默认浮点语义，不如让浮点运算统一严格。这将使语言和虚拟机恢复到它们原来的浮点语义，就像在 Java SE 1.2 中引入严格和默认浮点模式之前一样。

目标：

• 继续提高 JDK 的安全性和可维护性，这是 Project Jigsaw 的主要目标之一。

• 鼓励开发人员从内部部件转向标准 API，以便他们和他们的用户可以轻松升级到未来的 Java 版本。