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

来源: OSCHINA
2021-08-31

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

JDK 17 等 LTS 版本每三年发布一次,上一个LTS 版本 JDK 11 于 2018 年 9 月发布。

详情可查看: https://jdk.java.net/17/ 

展开阅读全文
8 收藏
分享
加载中
精彩评论
java8永远滴神
2021-08-31 13:51
12
举报
个人玩家准备升级了
2021-08-31 08:02
9
举报
你这机器人问了这么多年 还是没有什么长进 学废了吧 自己不会找答案嘛?
2021-09-01 07:01
7
举报
用graalvm编译本地执行文件的话, 反射基本就废了, 所以spring系列也废了, 除了语法你还能熟悉外, 基本其他框架都要用无反射行为的框架, 比如Quarkus
2021-08-31 13:43
7
举报
I_I
希望快点把native搞成熟,早日脱离JVM的枷锁
2021-08-31 20:58
4
举报
最新评论 (83)
Java6用的好好的....
2021-09-16 17:20
0
回复
举报
下个lst版本就是java21了
2021-09-15 10:26
0
回复
举报
你更你的,我用我的 java 8
2021-09-06 08:32
0
回复
举报
Java8还没研究透,17都要出了
2021-09-06 08:22
0
回复
举报
java8的延长支持甚至可以到2030年,比11和17的还要晚结束
2021-09-05 11:24
0
回复
举报
好耶,这样是不是就会有更多的人从8升级到11了呢
2021-09-03 08:38
0
回复
举报
准备升级试一试了
2021-09-02 17:57
0
回复
举报
基于业界现状,新特性建议对比11或8
2021-09-02 15:35
1
回复
举报
没有project loom,没什么亮点,继续jdk8了
2021-09-02 07:12
0
回复
举报
我爱c#
2021-09-01 20:56
0
回复
举报
更多评论
83 评论
8 收藏
分享
返回顶部
顶部