简介

2021 年 9 月 JDK17 发布了，JDK17 是最新的一个 LTS 版本。所谓 LTS 版本就是可以得到至少八年产品支持的版本。从 2014 年的 JDK8，到 2018 年的 JDK11，再到 2021 年的 JDK17。

同时 Oracle 也调整了 LTS 版本的发布年限，从之前的三年调整到现在的二年，也就是说下一个 LTS 版本将会是 JDK21，哇喔！

那么如果不是 LTS 版本呢? 非 LTS 版本只会得到六个月的产品支持。所以大家还是使用 LTS 版本吧。

好了，让我们一起来看看 JDK17 中都有那些新特性吧。

JDK17 中的新特性

总中的来说，JDK17 提供了 14 个优化点或者是变动点。我们会一一进行讲解。

语言上的新特性

JDK17 在语言上的新特性只有一个 JEP 409: Sealed Classes。

Sealed Classes 是在 JDK15 中引入的概念，它表示某个类允许哪些类来继承它：

public sealed class SealExample permits Seal1, Seal2{}
public non-sealed class Seal1 extends SealExample {}
public final class Seal2 extends SealExample {}

final 表示 Seal2 不能再被继承了。non-sealed 表示可以允许任何类继承。

核心库的优化

JDK17 对 JAVA 核心库的优化有 4 个。

• 第一个是：JEP 306: Restore Always-Strict Floating-Point Semantics

这个是什么呢？简单点说，就是之前的硬件架构，在严格进行浮点语义进行计算的时候，会消耗大量资源。这在很久以前硬件水平都不高的时候，是难以容忍的。

所以在 JDK1.2 之后，对浮点语义进行了微调,对默认的严格浮点语义进行了修改。

但是现在已经是 2021 年了，硬件水平得到了飞速的发展，所以之前引入的修改已经是不必要了，在 JDK17 中被废弃了。

• 第二个是：JEP 356: Enhanced Pseudo-Random Number Generator

JDK 中有一个专门生成随机数的类 java.util.Random，但是这个类生成的都是伪随机数。

JDK17 对这个类进行了加强，提供了一个 RandomGenerator 接口，为所有的伪随机数提供统一的 API。

RandomGenerators 提供了 ints、longs、doubles、nextBoolean、nextInt、nextLong、nextDouble 和 nextFloat 等方法，来生成对应的随机数。

RandomGenerator 接口又包括 4 个子接口，分别是：

SplittableRandomGenerator:提供了 split 和 splits 的方法，允许用户从现有的 RandomGenerator 生成一个新的 RandomGenerator.

JumpableRandomGenerator:扩展了 RandomGenerator 的 jump 和 jumps 的方法,允许用户跳过一定数目的随机数。

LeapableRandomGenerator :扩展了 RandomGenerator 的 leap 和 leaps 的方法,允许用户跳过大量数目的随机数。

ArbitrouslyJumpableRandomGenerator:扩展了 LeapableRandomGenerator,允许用户指定跳过的随机数。

同时还对 Random、ThreadLocalRandom 和 SplittableRandom 等类进行了重构。

• 第三个是 JEP 382: New macOS Rendering Pipeline

这个是专门为 Mac 做的优化，使用了最新的 Apple Metal API 来实现 JAVA 的 2D 渲染。

• 第四个是 JEP 415: Context-Specific Deserialization Filters

JDK 中一个很危险的用法就是反序列化，因为你不知道反序列化的对象到底是不是一个危险的对象，为了解决这个问题，在 Java 9 中引入了反序列化过滤器，从而在反序列化之前对数据流进行验证。

但是这种基于流的过滤器有几个限制，这种方法不能扩展，并且很难在代码发布后更新过滤器。它也不能对应用程序中第三方库执行的反序列化操作进行过滤。

为了解决这些问题，JEP 290 还引入了一个 JVM 范围的反序列化过滤器，可以通过 API、系统属性或安全属性进行设置。但是这种静态的过滤器，在具有多个执行上下文的复杂应用程序中,往往会不太适用，因为不同的上下文可能需要不同的过滤条件。

JDK17 对 JDK9 的过滤方法进行了改进，可以在 JVM 范围配置特定于上下文的反序列化过滤器。

支持新的平台

• JEP 391: macOS AArch 64 Port

Mac 的 M1 芯片都发布好久了，没有理由 JDK 不支持，这个 JEP 就是让 JDK17 支持原生的 Apple 的新 Arm 64 架构。

预览特性

• JEP 406: Pattern Matching for switch (Preview)

这个新特性允许在 switch 中使用模式匹配。

我们知道，在之前的预览功能中，已经有模式匹配了，不过模式匹配是用在 instance of 语句中，如下所示：

// Old codeif (o instanceof String) {    String s = (String)o;    ... use s ...}
// New codeif (o instanceof String s) {    ... use s ...}

但是如果 instanceof 太多的话，也会造成困扰：

static String formatter(Object o) {    String formatted = "unknown";    if (o instanceof Integer i) {        formatted = String.format("int %d", i);    } else if (o instanceof Long l) {        formatted = String.format("long %d", l);    } else if (o instanceof Double d) {        formatted = String.format("double %f", d);    } else if (o instanceof String s) {        formatted = String.format("String %s", s);    }    return formatted;}

最好的办法是将上面的代码转换成为 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();    };}

这就是 switch 中的模式匹配。

• JEP 412: Foreign Function and Memory API (Incubator)

在 JDK14 和 15 中，JDK 已经可以调用不属于 JVM 内部的代码和访问不归 JVM 管辖的内存空间。这个新特性在 JDK17 中得到了增强。

想象一下，以后 JDK 可以原生支持调用非 java 语言的 API，是不是很厉害？

• JEP 414: Vector API (Second Incubator)

Vector 是在 JDK16 中引入的。可以让向量计算更加快速。 循环遍历的计算，可以用 Vector 来进行简化。

其他改动

其他的一些改动比如封装 JDK 内部使用的 API ,废弃了 Security Manager,Applet API 和 RMI 等等，这里就不一一介绍了。

总结

JDK17 是一个 LTS 版本，也提供了很多优秀的新特性，还不赶紧用起来！

本文已收录于 http://www.flydean.com/27-jdk17-new-features/

最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！

欢迎关注我的公众号:「程序那些事」,懂技术，更懂你！