JDK17 来了！不好意思，我还在用JDK8！

往期热门文章：
1、推荐一款 Spring Boot 的 HTTP 客户端框架
2、牛逼！SpringBoot+Vue企业级支付系统！附源码！
3、面试官：二维码扫码登录是个啥原理
4、Spring Boot + Vue 如此强大？

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

如果看到这里，说明你喜欢这篇文章，请 转发、点赞。同时 标星（置顶）本公众号可以第一时间接受到博文推送。
推荐阅读：（点击标题可跳转）

这 56 个代码注释让我笑吐了
基于 SpringBoot + Vue 的前后端分离的考试系统
干掉 XML Mapper，新出的 Fluent Mybatis 真香！
最牛逼的性能监控系统！集强大功能于一身
21 款 yyds 的 IDEA插件

编程·技术·经验
欢迎扫码关注