阿里园区双 11 - 程序猿阿朗
阿里园区在每年双十一 都会精心布置一 番，还会邀请同学亲友一起参观，不过今年由于疫情原因，原本计划的亲友游园会只能取消了。
Java 17 在 2021 年 9 月 14 日正式发布，Java 17 是一个长期支持（LTS）版本，这次更新共带来 14 个新功能。
OpenJDK Java 17 下载：https://jdk.java.net/archive/
OpenJDK Java 17 文档：https://openjdk.java.net/projects/jdk/17/
| 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 每个版本的新功能，可以点击浏览。
1. 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 修饰。
package com.wdbyte; public class Main { public static void main(String[] args) { testStrictfp(); } public strictfp static void testStrictfp() { float aFloat = 0.6666666666666666666f; double aDouble = 0.88888888888888888d; double sum = aFloat + aDouble; System.out.println("sum: " + sum); } }
2. JEP 356：增强的伪随机数生成器
为伪随机数生成器 RPNG（pseudorandom number generator）增加了新的接口类型和实现，让在代码中使用各种 PRNG 算法变得容易许多。
这次增加了 RandomGenerator 接口，为所有的 PRNG 算法提供统一的 API，并且可以获取不同类型的 PRNG 对象流。同时也提供了一个新类 RandomGeneratorFactory 用于构造各种 RandomGenerator 实例，在 RandomGeneratorFactory 中使用 ServiceLoader.provider 来加载各种 PRNG 实现。
下面是一个使用示例：随便选择一个 PRNG 算法生成 5 个 10 以内的随机数。
package com.wdbyte.java17; import java.util.Date; import java.util.random.RandomGenerator; import java.util.random.RandomGeneratorFactory; import java.util.stream.Stream; /** * @author niulang */ public class JEP356 { public static void main(String[] args) { RandomGeneratorFactory<RandomGenerator> l128X256MixRandom = RandomGeneratorFactory.of("L128X256MixRandom"); // 使用时间戳作为随机数种子 RandomGenerator randomGenerator = l128X256MixRandom.create(System.currentTimeMillis()); for (int i = 0; i < 5; i++) { System.out.println(randomGenerator.nextInt(10)); } } }
得到输出：
7 3 4 4 6
你也可以遍历出所有的 PRNG 算法。
RandomGeneratorFactory.all().forEach(factory -> { System.out.println(factory.group() + ":" + factory.name()); });
得到输出：
LXM:L32X64MixRandom LXM:L128X128MixRandom LXM:L64X128MixRandom Legacy:SecureRandom LXM:L128X1024MixRandom LXM:L64X128StarStarRandom Xoshiro:Xoshiro256PlusPlus LXM:L64X256MixRandom Legacy:Random Xoroshiro:Xoroshiro128PlusPlus LXM:L128X256MixRandom Legacy:SplittableRandom LXM:L64X1024MixRandom
可以看到 Legacy:Random 也在其中，新的 API 兼容了老的 Random 方式，所以你也可以使用新的 API 调用 Random 类生成随机数。
// 使用 Random RandomGeneratorFactory<RandomGenerator> l128X256MixRandom = RandomGeneratorFactory.of("Random"); // 使用时间戳作为随机数种子 RandomGenerator randomGenerator = l128X256MixRandom.create(System.currentTimeMillis()); for (int i = 0; i < 5; i++) { System.out.println(randomGenerator.nextInt(10)); }
3. JEP 382：使用新的 macOS 渲染库
macOS 为了提高图形的渲染性能，在 2018 年 9 月抛弃了之前的 OpenGL 渲染库 ，而使用了 Apple Metal 进行代替。Java 17 这次更新开始支持 Apple Metal，不过对于 API 没有任何改变，这一些都是内部修改。
4. JEP 391：支持 macOS/AArch64 架构
起因是 Apple 在 2020 年 6 月的 WWDC 演讲中宣布，将开启一项长期的将 Macintosh 计算机系列从 x64 过度到 AArch64 的长期计划，因此需要尽快的让 JDK 支持 macOS/AArch64 。
Linux 上的 AArch64 支持以及在 Java 16 时已经支持，可以查看之前的文章了解。
5. JEP 398：删除已弃用的 Applet API
Applet 是使用 Java 编写的可以嵌入到 HTML 中的小应用程序，嵌入方式是通过普通的 HTML 标记语法，由于早已过时，几乎没有场景在使用了。
示例：嵌入 Hello.class
<applet code="Hello.class" height=200 width=200></applet>
Applet API 在 Java 9 时已经标记了废弃，现在 Java 17 中将彻底删除。
6. 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 选项将会得到一个命令已经移除的警告。
➜ bin ./java -version openjdk version "17" 2021-09-14 OpenJDK Runtime Environment (build 17+35-2724) OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing) ➜ bin ./java --illegal-access=warn OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=warn; support was removed in 17.0
7. JEP 406：switch 的类型匹配（预览）
如 instanceof 一样，为 switch 也增加了类型匹配自动转换功能。
在之前，使用 instanceof 需要如下操作：
if (obj instanceof String) { String s = (String) obj; // grr... ... }
多余的类型强制转换，而现在：
if (obj instanceof String s) { // Let pattern matching do the work! ... }
switch 也可以使用类似的方式了。
static String formatterPatternSwitch(Object o) { return switch (o) { case Integer i -> String.format("int %d", i); case Long l -> String.format("long %d", l); case Double d -> String.format("double %f", d); case String s -> String.format("String %s", s); default -> o.toString(); }; }
对于 null 值的判断也有了新的方式。
// Java 17 之前 static void testFooBar(String s) { if (s == null) { System.out.println("oops!"); return; } switch (s) { case "Foo", "Bar" -> System.out.println("Great"); default -> System.out.println("Ok"); } } // Java 17 static void testFooBar(String s) { switch (s) { case null -> System.out.println("Oops"); case "Foo", "Bar" -> System.out.println("Great"); default -> System.out.println("Ok"); } }
8. JEP 407：移除 RMI Activation
移除了在 JEP 385 中被标记废除的 RMI（Remote Method Invocation）Activation，但是 RMI 其他部分不会受影响。
RMI Activation 在 Java 15 中的 JEP 385 已经被标记为过时废弃，至今没有收到不良反馈，因此决定在 Java 17 中正式移除。
9. JEP 409：密封类（Sealed Classes）
Sealed Classes 在 Java 15 中的 JEP 360 中提出，在 Java 16 中的 JEP 397 再次预览，现在 Java 17 中成为正式的功能，相比 Java 16 并没有功能变化，这里不再重复介绍，想了解的可以参考之前文章。
10. 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
11. JEP 411：弃用 Security Manager
Security Manager 在 JDK 1.0 时就已经引入，但是它一直都不是保护服务端以及客户端 Java 代码的主要手段，为了 Java 的继续发展，决定弃用 Security Manager，在不久的未来进行删除。
@Deprecated(since="17", forRemoval=true) public class SecurityManager { // ... }
12. 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（孵化器）。
13. JEP 414：Vector API（二次孵化）
在 Java 16 中引入一个新的 API 来进行向量计算，它可以在运行时可靠的编译为支持的 CPU 架构，从而实现更优的计算能力。
现在 Java 17 中改进了 Vector API 性能，增强了例如对字符的操作、字节向量与布尔数组之间的相互转换等功能。
14. JEP 415：指定上下文的反序列化过滤器
Java 中的序列化一直都是非常重要的功能，如果没有序列化功能，Java 可能都不会占据开发语言的主导地位，序列化让远程处理变得容易和透明，同时也促进了 Java EE 的成功。
但是 Java 序列化的问题也很多，它几乎会犯下所有的可以想象的错误，为开发者带来持续的维护工作。但是要说明的是序列化的概念是没有错的，把对象转换为可以在 JVM 之间自由传输，并且可以在另一端重新构建的能力是完全合理的想法，问题在于 Java 中的序列化设计存在风险，以至于爆出过很多和序列化相关的漏洞。
反序列化危险的一个原因是，有时候我们不好验证将要进行反序列化的内容是否存在风险，而传入的数据流可以自由引用对象，很有可能这个数据流就是攻击者精心构造的恶意代码。
所以，JEP 415 允许在反序列化时，通过一个过滤配置，来告知本次反序列化允许或者禁止操作的类，反序列化时碰到被禁止的类，则会反序列化失败。
14.1. 反序列化示例
假设 Dog 类中的 Poc 是恶意构造的类，但是正常反序列化是可以成功的。
package com.wdbyte.java17; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; /** * @author niulang */ public class JEP415 { public static void main(String[] args) throws IOException, ClassNotFoundException { Dog dog = new Dog("哈士奇"); dog.setPoc(new Poc()); // 序列化 - 对象转字节数组 ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); try (ObjectOutputStream objectOutputStream = new ObjectOutputStream(byteArrayOutputStream);) { objectOutputStream.writeObject(dog); } byte[] bytes = byteArrayOutputStream.toByteArray(); // 反序列化 - 字节数组转对象 ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(bytes); ObjectInputStream objectInputStream = new ObjectInputStream(byteArrayInputStream); Object object = objectInputStream.readObject(); System.out.println(object.toString()); } } class Dog implements Serializable { private String name; private Poc poc; public Dog(String name) { this.name = name; } @Override public String toString() { return "Dog{" + "name='" + name + '\'' + '}'; } // get...set... } class Poc implements Serializable{ }
输出结果：
Dog{name='哈士奇'}
14.2. 反序列化过滤器
在 Java 17 中可以自定义反序列化过滤器，拦截不允许的类。
package com.wdbyte.java17; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputFilter; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; /** * @author niulang */ public class JEP415 { public static void main(String[] args) throws IOException, ClassNotFoundException { Dog dog = new Dog("哈士奇"); dog.setPoc(new Poc()); // 序列化 - 对象转字节数组 ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); try (ObjectOutputStream objectOutputStream = new ObjectOutputStream(byteArrayOutputStream);) { objectOutputStream.writeObject(dog); } byte[] bytes = byteArrayOutputStream.toByteArray(); // 反序列化 - 字节数组转对象 ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(bytes); ObjectInputStream objectInputStream = new ObjectInputStream(byteArrayInputStream); // 允许 com.wdbyte.java17.Dog 类，允许 java.base 中的所有类，拒绝其他任何类 ObjectInputFilter filter = ObjectInputFilter.Config.createFilter( "com.wdbyte.java17.Dog;java.base/*;!*"); objectInputStream.setObjectInputFilter(filter); Object object = objectInputStream.readObject(); System.out.println(object.toString()); } } class Dog implements Serializable { private String name; private Poc poc; public Dog(String name) { this.name = name; } @Override public String toString() { return "Dog{" + "name='" + name + '\'' + '}'; } // get...set... } class Poc implements Serializable{ }
这时反序列化会得到异常。
Exception in thread "main" java.io.InvalidClassException: filter status: REJECTED at java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1412) at java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2053) at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1907) ....
