JDK 17_Java 17 中的新特性

• 特定于上下文的反序列化过滤器允许应用程序通过调用 JVM 范围的过滤器工厂来配置特定于上下文和动态选择的反序列化过滤器，以便为每个序列化操作选择一个过滤器。在解释该提议背后的动机时，Oracle 表示反序列化不受信任的数据本质上是一种危险的活动，因为传入数据流的内容决定了创建的对象、其字段的值以及它们之间的引用。在许多用途中，流中的字节是从未知、不受信任或未经身份验证的客户端接收的。通过仔细构建流，攻击者可以导致恶意执行任意类中的代码。如果对象构造具有改变状态或调用其他操作的副作用，则这些操作可能会危及应用程序对象的完整性，库对象和 Java 运行时。禁用序列化攻击的关键是防止任意类的实例被反序列化，从而防止直接或间接执行它们的方法。反序列化过滤器被引入Java 9使应用程序和库代码能够在反序列化之前验证传入的数据流。此代码java.io.ObjectInputFilter在创建反序列化流时提供验证逻辑。但是，依赖流的创建者来明确请求验证有局限性。JDK Enhancement Proposal 290通过引入可通过 API、系统属性或安全属性设置的 JVM 范围的反序列化过滤器解决了这些限制，但这种方法也有局限性，尤其是在复杂的应用程序中。更好的方法是配置每个流过滤器，这样它们就不需要每个流创建者的参与。计划中的增强应帮助开发人员为每个反序列化上下文和用例构建和应用适当的过滤器。
• 随着always-strict 浮点语义的恢复，浮点运算将变得始终严格，而不是同时具有严格的浮点语义 ( strictfp) 和细微不同的默认浮点语义。这将原始浮点语义恢复到语言和 VM，匹配 Java 标准版 1.2 中引入严格和默认浮点模式之前的语义。这项工作的目标包括简化数字敏感库的开发，包括java.lang.Math和java.lang.StrictMath. 1990 年代后期更改默认浮点语义的动力源于原始 Java 语言和 JVM 语义之间的不良交互以及流行的 x86 架构的 x87 浮点协处理器指令集的一些特殊性。在所有情况下匹配精确的浮点语义，包括非正规操作数和结果，需要大量额外指令的开销。在没有上溢或下溢的情况下匹配结果可以用更少的开销来完成，这大致是 Java SE 1.2 中引入的修改后的默认浮点语义所允许的。但是 SSE2（Streaming SIMD Extensions 2）扩展，从 2001 年左右开始在 Pentium 4 和更高版本的处理器中提供，可以以直接的方式支持严格的 JVM 浮点运算，而不会产生过多的开销。
• 弃用安全管理器，准备在未来版本中移除。追溯到 Java 1.0，安全管理器一直是保护客户端 Java 代码的主要手段，很少用于保护服务器端代码。该提案的一个目标是评估是否需要新的 API 或机制来解决使用安全管理器的特定狭窄用例，例如阻塞System::exit。计划要求弃用安全管理器以与旧 Applet API 一起删除，该 API 也计划在 JDK 17 中弃用。
• 模式匹配switch预览版扩展了 Java 中的模式语言，允许switch针对多个模式测试表达式和语句，每个模式都有特定的操作。这使得复杂的面向数据的查询能够简洁而安全地表达。此功能的目标包括switch通过使模式出现在案例标签中来扩展表达式和语句的表达能力和应用，放松历史对switch何时需要的空敌意，以及引入两种模式：guarded patterns，允许模式匹配逻辑用任意布尔表达式和 精炼parenthesized patterns，解决了一些解析歧义。在JDK 16 中，instanceof运算符被扩展为采用类型模式并执行模式匹配。提议的适度扩展允许简化熟悉的 instanceof-and-cast 习语。
• JDK 内部的强封装，除了关键的内部 API，如sun.misc.Unsafe，将不再可能通过单个命令行选项放松内部元素的强封装，这在 JDK 9 到 JDK 16 中是可行的。计划包括提高 JDK 的安全性和可维护性，并鼓励开发人员从内部元素迁移到标准 API。
• 删除远程方法调用 (RMI) 激活机制，同时保留 RMI 的其余部分。RMI 激活机制已过时和废弃，在JDK 15 中不推荐使用。
• 在国外功能和记忆API，引入了一个孵化器阶段，允许 Java 程序与 Java 运行时之外的代码和数据进行互操作。通过高效调用外部函数，即 JVM 之外的代码，并安全地访问外部内存，即非 JVM 管理的内存，该 API 使 Java 程序能够调用原生库和处理原生数据，而没有 JNI（Java本机接口）。提议的 API 是两个 API 的演变——外部内存访问 API 和外部链接器 API。外部内存访问 API 在 2019 年作为孵化 API 面向 Java 14，并在 Java 15 和 Java 16 中重新孵化。外部链接器 API 在 2020 年末面向 Java 16 作为孵化 API。API 计划的目标包括易用性、性能、通用性和安全性。
• 与平台无关的向量 API作为孵化 API集成到JDK 16中，将在 JDK 17 中再次孵化，提供一种机制来表达向量计算，这些计算在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令。这比等效的标量计算获得了更好的性能。在 JDK 17 中，向量 API 已针对性能和实现进行了增强，包括在字节向量与布尔数组之间进行转换的增强功能。
• 密封类和接口限制哪些其他类或接口可以扩展或实现它们。该提案的目标包括允许类或接口的作者控制哪些代码负责实现它，提供比访问修饰符更具声明性的方式来限制超类的使用，并通过提供基础支持模式匹配的未来方向用于模式的详尽分析。
• 删除实验性 AOT 和 JIT 编译器，它们很少使用，但需要大量维护工作。该计划要求维护 Java 级别的 JVM 编译器接口，以便开发人员可以继续使用外部构建的编译器版本进行 JIT 编译。AOT 编译（jaotc 工具）作为一项实验性功能并入JDK 9。该工具使用Graal 编译器，它本身是用 Java 编写的，用于 AOT 编译。这些实验性功能未包含在JDK 16 中由 Oracle 发布的版本，没有人抱怨。根据规定的计划，将删除三个 JDK 模块： jdk.aot（jaotc 工具）；internal.vm.compiler，Graal 编译器；和 jdk.internal.vm.compiler.management，Graal MBean。与 AOT 编译相关的 HotSpot 代码也将被删除。
• 将 JDK 移植到 MacOS/AArch64以响应Apple 将其 Macintosh 计算机从 x64 转换到 AArch64 的计划。适用于 Linux 的 Java 的 AArch64 端口已经存在，并且 Windows 的工作正在进行中。Java 构建者希望通过使用条件编译来重用来自这些端口的现有 AArch64 代码，这是 JDK 端口中的规范，以适应低级约定的差异，例如应用程序二进制接口和一组保留的处理器寄存器。MacOS/AArch64 的更改可能会破坏现有的 Linux/AArch64、Windows/AArch64 和 MacOS/x64 端口，但通过预集成测试将降低风险。
• 弃用 Applet API 以进行删除。这个 API 本质上是无关紧要的，因为所有 Web 浏览器供应商要么已经取消了对 Java 浏览器插件的支持，要么已经宣布了这样做的计划。Applet API 之前在 2017 年 9 月的Java 9中已被弃用，但并未删除。
• 用于 MacOS 的新渲染管道，使用 Apple Metal API 作为使用已弃用 OpenGL API 的现有管道的替代方案。该提案旨在为使用 MacOS Metal 框架的 Java 2D API 提供功能齐全的渲染管道，并在 Apple 从未来版本的 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。

JDK17新特性 JAVA17新特性 Java17

http://blog.xqlee.com/article/879.html