Java 17 的新特性

Sievy Matt

已于 2022-08-09 16:22:49 修改

阅读量2k

点赞数

分类专栏： Java 文章标签： java jvm

于 2022-08-09 16:13:17 首次发布

原文链接：https://baijiahao.baidu.com/s?id=1707795040283053701&wfr=spider&for=pc

版权

Java 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Java 17 的新特性

作为 JDK 17 的一部分，Java 17 具有以下提议的特性:

JEP 415：特定于上下文的反序列化过滤器
JEP 414：Vector API（第二个孵化器）
JEP 412：外部函数和内存 API（孵化器）
JEP 411：弃用安全管理器以进行删除
JEP 410：删除实验性 AOT 和 JIT 编译器
JEP 409：密封类
JEP 407：删除 RMI 激活
JEP 406：开关模式匹配（预览）
JEP 403：强封装 JDK 内部
JEP 398：弃用 Applet API 以进行删除
JEP 391：macOS/AArch64 端口
JEP 382：新的 macOS 渲染管线
JEP 356：增强型伪随机数生成器
JEP 306：恢复始终严格的浮点语义

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子句指定允许/允许扩展密封类的类。

示例：下面的示例显示了 Animal 类如何指定三个允许的子类：

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

注意： permit 指定的类必须位于靠近超类的位置，或者在同一个模块中，或者在同一个包中。

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{....}