这是我参与11月更文挑战的第2天,活动详情查看:2021最后一次更文挑战
点赞再看,动力无限。Hello world : ) 微信搜「 程序猿阿朗 」。
本文 Github.com/niumoo/Java… 和 未读代码博客 已经收录,有很多知识点和系列文章。
Java 17 在 2021 年 9 月 14 日正式发布,Java 17 是一个长期支持(LTS)版本,这次更新共带来 14 个新功能。
OpenJDK Java 17 下载:jdk.java.net/archive/
OpenJDK Java 17 文档:openjdk.java.net/projects/jd…
JEP | 描述 |
---|---|
JEP 306 | 恢复始终严格的浮点语义 |
JEP 356 | 增强的伪随机数生成器 |
JEP 382 | 使用新的 macOS 渲染库 |
JEP 391 | 支持 macOS/AArch64 架构 |
JEP 398 | 删除已启用的 Applet API |
JEP 403 | 更强的封装 JDK 内部封装 |
JEP 406 | Switch 模式匹配(预览) |
JEP 407 | 移除 RMI Activation |
JEP 409 | 密封类(Sealed Classes) |
JEP 410 | JEP 401:移除实验性的 AOT 和 JIT 编译器 |
JEP 411 | 弃用 Security Manager |
JEP 412 | 外部函数和内存 API(孵化器) |
JEP 414 | Vector API(第二孵化器) |
JEP 415 | 指定上下文的反序列化过滤器 |
此文章属于 Java 新特性教程 系列,会介绍 Java 每个版本的新功能,可以点击浏览。
- JEP 306: 恢复始终严格的浮点语义
既然是恢复严格的浮点语义,那么说明在某个时间点之前,是始终严格的浮点语义的。其实在 Java SE 1.2 之前,所有的浮点计算都是严格的,但是以当初的情况来看,过于严格的浮点计算在当初流行的 x86 架构和 x87 浮点协议处理器上运行,需要大量的额外的指令开销,所以在 Java SE 1.2 开始,需要手动使用关键字 strictfp(strict float point) 才能启用严格的浮点计算。
但是在 2021 年的今天,硬件早已发生巨变,当初的问题已经不存在了,所以从 Java 17 开始,恢复了始终严格的浮点语义这一特性。
扩展:strictfp 是 Java 中的一个关键字,大多数人可能没有注意过它,它可以用在类、接口或者方法上,被 strictfp 修饰的部分中的 float 和 double 表达式会进行严格浮点计算。
下面是一个示例,其中的 testStrictfp()
被 strictfp
修饰。
1 | java复制代码package com.wdbyte; |
- JEP 356:增强的伪随机数生成器
为伪随机数生成器 RPNG(pseudorandom number generator)增加了新的接口类型和实现,让在代码中使用各种 PRNG 算法变得容易许多。
这次增加了 RandomGenerator
接口,为所有的 PRNG 算法提供统一的 API,并且可以获取不同类型的 PRNG 对象流。同时也提供了一个新类 RandomGeneratorFactory
用于构造各种 RandomGenerator
实例,在 RandomGeneratorFactory
中使用 ServiceLoader.provider
来加载各种 PRNG 实现。
下面是一个使用示例:随便选择一个 PRNG 算法生成 5 个 10 以内的随机数。
1 | java复制代码package com.wdbyte.java17; |
得到输出:
1 | shell复制代码7 |
你也可以遍历出所有的 PRNG 算法。
1 | java复制代码RandomGeneratorFactory.all().forEach(factory -> { |
得到输出:
1 | shell复制代码LXM:L32X64MixRandom |
可以看到 Legacy:Random
也在其中,新的 API 兼容了老的 Random
方式,所以你也可以使用新的 API 调用 Random
类生成随机数。
1 | java复制代码// 使用 Random |
扩展阅读:增强的伪随机数生成器
- JEP 382:使用新的 macOS 渲染库
macOS 为了提高图形的渲染性能,在 2018 年 9 月抛弃了之前的 OpenGL 渲染库 ,而使用了 Apple Metal 进行代替。Java 17 这次更新开始支持 Apple Metal,不过对于 API 没有任何改变,这一些都是内部修改。
- JEP 391:支持 macOS/AArch64 架构
起因是 Apple 在 2020 年 6 月的 WWDC 演讲中宣布,将开启一项长期的将 Macintosh 计算机系列从 x64 过度到 AArch64 的长期计划,因此需要尽快的让 JDK 支持 macOS/AArch64 。
Linux 上的 AArch64 支持以及在 Java 16 时已经支持,可以查看之前的文章了解。
- JEP 398:删除已弃用的 Applet API
Applet 是使用 Java 编写的可以嵌入到 HTML 中的小应用程序,嵌入方式是通过普通的 HTML 标记语法,由于早已过时,几乎没有场景在使用了。
示例:嵌入 Hello.class
1 | html复制代码<applet code="Hello.class" height=200 width=200></applet> |
Applet API 在 Java 9 时已经标记了废弃,现在 Java 17 中将彻底删除。
- JEP 403:更强的 JDK 内部封装
如 Java 16 的 JEP 396 中描述的一样,为了提高 JDK 的安全性,使 --illegal-access
选项的默认模式从允许更改为拒绝。通过此更改,JDK 的内部包和 API(关键内部 API 除外)将不再默认打开。
但是在 Java 17 中,除了 sun.misc.Unsafe
,使用 --illegal-access
命令也不能打开 JDK 内部的强封装模式了,除了 sun.misc.Unsafe
API .
在 Java 17 中使用 --illegal-access
选项将会得到一个命令已经移除的警告。
1 | shell复制代码➜ bin ./java -version |
- JEP 406:switch 的类型匹配(预览)
如 instanceof
一样,为 switch
也增加了类型匹配自动转换功能。
在之前,使用 instanceof
需要如下操作:
1 | java复制代码if (obj instanceof String) { |
多余的类型强制转换,而现在:
1 | java复制代码if (obj instanceof String s) { |
switch
也可以使用类似的方式了。
1 | java复制代码static String formatterPatternSwitch(Object o) { |
对于 null
值的判断也有了新的方式。
1 | java复制代码// Java 17 之前 |
扩展阅读: JEP 406:switch 的类型匹配(预览)
- JEP 407:移除 RMI Activation
移除了在 JEP 385 中被标记废除的 RMI(Remote Method Invocation)Activation,但是 RMI 其他部分不会受影响。
RMI Activation 在 Java 15 中的 JEP 385 已经被标记为过时废弃,至今没有收到不良反馈,因此决定在 Java 17 中正式移除。
- JEP 409:密封类(Sealed Classes)
Sealed Classes 在 Java 15 中的 JEP 360 中提出,在 Java 16 中的 JEP 397 再次预览,现在 Java 17 中成为正式的功能,相比 Java 16 并没有功能变化,这里不再重复介绍,想了解的可以参考之前文章。
- JEP 401:移除实验性的 AOT 和 JIT 编译器
在 Java 9 的 JEP 295 中,引入了实验性的提前编译 jaotc 工具,但是这个特性自从引入依赖用处都不太大,而且需要大量的维护工作,所以在 Java 17 中决定删除这个特性。
主要移除了三个 JDK 模块:
- jdk.aot - jaotc 工具。
- Jdk.internal.vm.compiler - Graal 编译器。
- jdk.internal.vm.compiler.management
同时也移除了部分与 AOT 编译相关的 HotSpot 代码:
src/hotspot/share/aot
— dumps and loads AOT code- Additional code guarded by
#if INCLUDE_AOT
- JEP 411:弃用 Security Manager
Security Manager 在 JDK 1.0 时就已经引入,但是它一直都不是保护服务端以及客户端 Java 代码的主要手段,为了 Java 的继续发展,决定弃用 Security Manager,在不久的未来进行删除。
1 | java复制代码@Deprecated(since="17", forRemoval=true) |
- JEP 412:外部函数和内存 API (孵化)
新的 API 允许 Java 开发者与 JVM 之外的代码和数据进行交互,通过调用外部函数,可以在不使用 JNI 的情况下调用本地库。
这是一个孵化功能;需要添加--add-modules jdk.incubator.foreign
来编译和运行 Java 代码。
历史
- Java 14 JEP 370引入了外部内存访问 API(孵化器)。
- Java 15 JEP 383引入了外部内存访问 API(第二孵化器)。
- Java 16 JEP 389引入了外部链接器 API(孵化器)。
- Java 16 JEP 393引入了外部内存访问 API(第三孵化器)。
- Java 17 JEP 412引入了外部函数和内存 API(孵化器)。
- JEP 414:Vector API(二次孵化)
在 Java 16 中引入一个新的 API 来进行向量计算,它可以在运行时可靠的编译为支持的 CPU 架构,从而实现更优的计算能力。
现在 Java 17 中改进了 Vector API 性能,增强了例如对字符的操作、字节向量与布尔数组之间的相互转换等功能。
- JEP 415:指定上下文的反序列化过滤器
Java 中的序列化一直都是非常重要的功能,如果没有序列化功能,Java 可能都不会占据开发语言的主导地位,序列化让远程处理变得容易和透明,同时也促进了 Java EE 的成功。
但是 Java 序列化的问题也很多,它几乎会犯下所有的可以想象的错误,为开发者带来持续的维护工作。但是要说明的是序列化的概念是没有错的,把对象转换为可以在 JVM 之间自由传输,并且可以在另一端重新构建的能力是完全合理的想法,问题在于 Java 中的序列化设计存在风险,以至于爆出过很多和序列化相关的漏洞。
反序列化危险的一个原因是,有时候我们不好验证将要进行反序列化的内容是否存在风险,而传入的数据流可以自由引用对象,很有可能这个数据流就是攻击者精心构造的恶意代码。
所以,JEP 415 允许在反序列化时,通过一个过滤配置,来告知本次反序列化允许或者禁止操作的类,反序列化时碰到被禁止的类,则会反序列化失败。
14.1. 反序列化示例
假设 Dog 类中的 Poc 是恶意构造的类,但是正常反序列化是可以成功的。
1 | java复制代码package com.wdbyte.java17; |
输出结果:
1 | ini复制代码Dog{name='哈士奇'} |
14.2. 反序列化过滤器
在 Java 17 中可以自定义反序列化过滤器,拦截不允许的类。
1 | java复制代码package com.wdbyte.java17; |
这时反序列化会得到异常。
1 | shell复制代码Exception in thread "main" java.io.InvalidClassException: filter status: REJECTED |
参考
<完>
文章持续更新,可以微信搜一搜「 程序猿阿朗 」或访问「程序猿阿朗博客 」第一时间阅读。本文 Github.com/niumoo/Java… 已经收录,有很多知识点和系列文章,欢迎Star。
本文转载自: 掘金