换掉 Java 8 ！Java 17 新特性真香
Guide 这里也是真的建议有条件的小伙伴尝试一波 Java 17！不要死守 Java 8 了！
Java 17
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 恢复始终严格的浮点语义[1]
JEP 356 增强的伪随机数生成器[2]
JEP 382 使用新的 macOS 渲染库[3]
JEP 391 支持 macOS/AArch64 架构[4]
JEP 398 删除已启用的 Applet API[5]
JEP 403 更强的封装 JDK 内部封装[6]
JEP 406 Switch 模式匹配（预览）[7]
JEP 407 移除 RMI Activation[8]
JEP 409 密封类（Sealed Classes）[9]
JEP 410 JEP 401：移除实验性的 AOT 和 JIT 编译器[10]
JEP 411 弃用 Security Manager[11]
JEP 412 外部函数和内存 API（孵化器）[12]
JEP 414 Vector API（第二孵化器）[13]
JEP 415 指定上下文的反序列化过滤器[14]
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 sms.reyo.cn;
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);
}
}
JEP 356：增强的伪随机数生成器
为伪随机数生成器 RPNG（pseudorandom number generator）增加了新的接口类型和实现，让在代码中使用各种 PRNG 算法变得容易许多。
这次增加了 RandomGenerator 接口，为所有的 PRNG 算法提供统一的 API，并且可以获取不同类型的 PRNG 对象流。同时也提供了一个新类 RandomGeneratorFactory 用于构造各种 RandomGenerator 实例，在 RandomGeneratorFactory 中使用 ServiceLoader.provider 来加载各种 PRNG 实现。
下面是一个使用示例：随便选择一个 PRNG 算法生成 5 个 10 以内的随机数。
package sms.reyo.cn;
import java.util.Date;
import java.util.random.RandomGenerator;
import java.util.random.RandomGeneratorFactory;
import java.util.stream.Stream;
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));
}
扩展阅读：增强的伪随机数生成器[15]
JEP 382：使用新的 macOS 渲染库
macOS 为了提高图形的渲染性能，在 2018 年 9 月抛弃了之前的 OpenGL 渲染库 ，而使用了 Apple Metal 进行代替。Java 17 这次更新开始支持 Apple Metal，不过对于 API 没有任何改变，这一些都是内部修改。
扩展阅读：macOS Mojave 10.14 Release Notes[16]，Apple Metal[17]
JEP 391：支持 macOS/AArch64 架构
起因是 Apple 在 2020 年 6 月的 WWDC 演讲中宣布，将开启一项长期的将 Macintosh 计算机系列从 x64 过度到 AArch64 的长期计划，因此需要尽快的让 JDK 支持 macOS/AArch64 。
Linux 上的 AArch64 支持以及在 Java 16 时已经支持，可以查看之前的文章了解。
扩展：Java 16 新功能介绍 - JEP 386[18]
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 中将彻底删除。
JEP 403：更强的 JDK 内部封装
如 Java 16 的 JEP 396 中描述的一样，为了提高 JDK 的安全性，使 --illegal-access 选项的默认模式从允许更改为拒绝。通过此更改，JDK 的内部包和 API（关键内部 API[19] 除外）将不再默认打开。
但是在 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
扩展阅读：JEP 403：更强的 JDK 内部封装[20]，Java 16 新功能介绍[21]
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");
}
}
扩展阅读：JEP 406：switch 的类型匹配（预览）[22]
JEP 407：移除 RMI Activation
移除了在 JEP 385 中被标记废除的 RMI（Remote Method Invocation）Activation，但是 RMI 其他部分不会受影响。
RMI Activation 在 Java 15 中的 JEP 385 已经被标记为过时废弃，至今没有收到不良反馈，因此决定在 Java 17 中正式移除。
扩展阅读：JEP 407：移除 RMI Activation[23]
JEP 409：密封类（Sealed Classes）
Sealed Classes 在 Java 15 中的 JEP 360 中提出，在 Java 16 中的 JEP 397 再次预览，现在 Java 17 中成为正式的功能，相比 Java 16 并没有功能变化，这里不再重复介绍，想了解的可以参考之前文章。
扩展阅读：Java 16 新功能介绍[24]，JEP 409: Sealed Classes[25]
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，在不久的未来进行删除。
@Deprecated(since="17", forRemoval=true)
public class SecurityManager {
// ...
}
JEP 412：外部函数和内存 API （孵化）
新的 API 允许 Java 开发者与 JVM 之外的代码和数据进行交互，通过调用外部函数，可以在不使用 JNI 的情况下调用本地库。
这是一个孵化功能；需要添加--add-modules jdk.incubator.foreign来编译和运行 Java 代码。
历史
Java 14 JEP 370[26]引入了外部内存访问 API（孵化器）。
Java 15 JEP 383[27]引入了外部内存访问 API（第二孵化器）。
Java 16 JEP 389[28]引入了外部链接器 API（孵化器）。
Java 16 JEP 393[29]引入了外部内存访问 API（第三孵化器）。
Java 17 JEP 412[30]引入了外部函数和内存 API（孵化器）。
扩展阅读：JEP 412：外部函数和内存 API （孵化）[31]
JEP 414：Vector API（二次孵化）
在 Java 16 中引入一个新的 API 来进行向量计算，它可以在运行时可靠的编译为支持的 CPU 架构，从而实现更优的计算能力。
现在 Java 17 中改进了 Vector API 性能，增强了例如对字符的操作、字节向量与布尔数组之间的相互转换等功能。
JEP 415：指定上下文的反序列化过滤器
Java 中的序列化一直都是非常重要的功能，如果没有序列化功能，Java 可能都不会占据开发语言的主导地位，序列化让远程处理变得容易和透明，同时也促进了 Java EE 的成功。
但是 Java 序列化的问题也很多，它几乎会犯下所有的可以想象的错误，为开发者带来持续的维护工作。但是要说明的是序列化的概念是没有错的，把对象转换为可以在 JVM 之间自由传输，并且可以在另一端重新构建的能力是完全合理的想法，问题在于 Java 中的序列化设计存在风险，以至于爆出过很多和序列化相关的漏洞。
反序列化危险的一个原因是，有时候我们不好验证将要进行反序列化的内容是否存在风险，而传入的数据流可以自由引用对象，很有可能这个数据流就是攻击者精心构造的恶意代码。
所以，JEP 415 允许在反序列化时，通过一个过滤配置，来告知本次反序列化允许或者禁止操作的类，反序列化时碰到被禁止的类，则会反序列化失败。
反序列化示例
假设 Dog 类中的 Poc 是恶意构造的类，但是正常反序列化是可以成功的。
package sms.reyo.cn;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
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='哈士奇'}
反序列化过滤器
在 Java 17 中可以自定义反序列化过滤器，拦截不允许的类。
package sms.reyo.cn;
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;
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) ....
扩展阅读：JEP 415：指定上下文的反序列化过滤器[32]
