JDK 20和JDK 21最新动态

JDK 20是自JDK 17,以来的第三个非长期支持（LTS）版本，正如甲骨文 Java 平台组的首席架构师Mark Reinhold所宣布的那样，它已经进入了初始候选版本阶段。主线源代码库已于 2022 年 12 月中旬（Rampdown 第一阶段）分支到 JDK稳定代码库，并定义了 JDK 20 的特性集。严重错误，如回归或严重的功能问题，可能会得到修复，但必须通过修复请求（Fix-Request）流程获得批准。根据发布时间表，JDK 20 将于 2023 年 3 月 21 日正式发布。值得注意的是，JEP 438 已于 2023 年 3 月初被添加到了特性集中。

最终包含了 7 个 JEP 形式的新特性，它们可以被分为两类：核心 Java 库和 Java 规范。

这些新特性中的 5 个被归类到了核心 Java 库中：

• JEP 429：作用域值（孵化器）
• JEP 434：外部函数和内存API（第二次预览）
• JEP 436：虚拟线程（第二次预览）
• JEP 437：结构化并发（第二个孵化器）
• JEP 438: Vector API (第五个孵化器)

这些新特性中有 2 个被归类到了 Java 规范中：

• JEP 432：记录模式（第二次预览）
• JEP 433：switch模式匹配（第四次预览）

我们研究了这些新特性以及支持它们的四个主要 Java 项目（Amber、Loom、Panama和Valhalla ），这些项目旨在孵化一系列组件，然后通过精心策划的合并最终将其纳入到 JDK 中。

Amber 项目

JEP 432，记录模式（第二次预览），为了响应上一轮预览JEP 405，记录模式（预览版）的反馈，它结合了增强功能。提议使用记录模式来增强语言，以解构记录值。记录模式可以与类型模式结合使用，以“实现一种强大的、声明式的、可组合的数据导航和处理形式”。类型模式最近通过 JDK 17 中提供的 JEP 406，switch模式匹配（预览版）和 JDK 18 中提供的 JEP 420，switch模式匹配（第二次预览）扩展到了 switch 语句标签中。与 JEP 405 相比，变化包括：增加了对泛型记录模式类型参数的推断支持；增加了对记录模式出现在增强 for 语句条件判断中的支持；并删除对了对命名记录模式的支持。

类似地，JEP 433：switch模式匹配（第四次预览），结合了增强功能以响应前三轮预览的反馈：JEP 427，switch模式匹配（第三次预览），在 JDK 19 中提供；JEP 420，switch模式匹配（第二次预览），在 JDK 18 中提供；以及 JEP 406，switch模式匹配（预览版），在 JDK 17 中提供。与 JEP 427 相比，变化包括：简化了 switch 标签语法；现在， switch 表达式和语句以及其他支持模式的构造体都支持泛型类型模式和记录模式的类型参数推断。

Loom 项目

JEP 429，作用域值（孵化器），一个正在孵化的 JEP，最初名为范围局部变量（孵化器，Extent-Local Variables），提议在线程内部和线程之间共享不可变数据。这比线程局部变量更可取，尤其是在使用大量虚拟线程时。

JEP 436，虚拟线程（第二次预览），提议基于 JDK 19 中所提供的 JEP 425，虚拟线程（预览版）对该特性进行第二次预览，以便留出时间来为该特性的演进提更多的反馈和体验。该特性为 Java 平台提供了虚拟线程，这是一种轻量级线程，可以极大地减少编写、维护和观察高吞吐量并发应用程序的工作量。需要注意的是，除了少量在 JDK19 中被被固化的 JEP 425 API 外，本预览版本没有进行任何更改，因此没有在第二次预览中提出。有关 JEP 425 的更多详细信息，请参阅 InfoQ 的新闻报道和甲骨文 Java 平台组 Java 开发人员倡导者José Paumard的 JEP Café屏幕截图。

JEP 437，结构化并发（第二个孵化器），提议基于 JDK 19 中所提供的 JEP 428，结构化并发（孵化器）重新孵化，以便留出时间来为该特性的演进提更多的反馈和体验。此特性的目的是通过引入一个库来将在不同线程中运行的多个任务视为单个工作单元，从而简化多线程编程。这可以简化错误处理和撤销，提高可靠性，并增强可观测性。唯一的变化是更新了 StructuredTaskScope 类，以支持在任务作用域中创建的线程可以继承作用域的值。这简化了线程间不可变数据的共享。有关 JEP 428 的更多详细信息，请参阅 InfoQ新闻报道。

Panama 项目

JEP 434，外部函数和内存API（第二次预览），基于反馈进行了改进，并基于 JDK 19 中所提供的 JEP 424，外部函数和内存API（预览版）进行了第二次预览。相关孵化包括 JEP 419，外部函数和内存API（第二个孵化器），在 JDK 18 中交付；以及 JEP 412，外部函数和内存API（孵化器），在 JDK 17 中交付。该特性为 Java 应用程序提供了一个 API，通过高效地调用外部函数和安全地访问不受 JVM 管理的外部内存，在 Java 运行时之外与代码和数据进行互操作。JEP 424 的更新包括：统一了 MemorySegment 和 MemoryAddress 接口，即，内存地址由零长度的内存段建模；并且增强了 MemoryLayout 密封接口，以便于与在 JDK 19 中提供的 JEP 427，switch中的模式匹配（第三次预览）一起使用。

JEP 438，Vector API(第五个孵化器)，结合了对前四轮孵化器反馈进行了增强：JEP 426，Vector API（第四个孵化器），在 JDK 19 中交付；JEP 417，Vector API（第三个孵化器），在 JDK 18 中交付；JEP 414，Vector API（第二个孵化器），在 JDK 17 中交付；JEP 338，Vector API（孵化器），作为 JDK 16 中的孵化器模块提供。该特性旨在增强 Vector API，以根据 JEP 424，外部函数和内存API（预览版）的定义，从 MemorySegment 中加载并存储向量。

JDK 21

计划于 2023 年 9 月发布一个 GA 和下一个 LTS 版本，目前JDK 21的 Proposed to Target 有两（2）个 JEP。

JEP 430，字符串模板（预览版），一种 JEP 类型的特性，提议使用字符串模板来增强 Java 编程语言，字符串模板类似于字符串字面量，但包含在运行时合并到字符串模板中的嵌入式表达式。该特性已被归类为 JDK 21 的 Proposed to Target，但尚未正式公布审查日期。

JEP 431，序列集合，提议引入“一个组能新表示集合概念的接口，这些集合的元素按照定义良好的序列或顺序排列，作为集合的结构属性。”其动因是由于集合框架（Collections Framework）中缺乏定义良好的排序和统一操作集。该特性已被归类为 JDK 21 的 Proposed to Target，但尚未正式公布审查日期。

我们可以根据一些 JEP 草案和候选版本来推测哪些额外的 JEP 有可能会被包含在 JDK21 中。

JEP 草案 8303358，作用域值（预览版），由红帽公司的杰出工程师Andrew Haley和Andrew Dinn提交，对即将发布的 JDK 20 中所提供的 JEP 429，作用域值（孵化器）进行了改进。其最初名为范围局部变量（孵化器，Extent-Local Variables），由Loom项目支持，该特性旨在实现线程内部和线程之间不可变数据的共享。这比线程局部变量更可取，尤其是在使用大量虚拟线程时。虽然这个草案还没有达到 Candidate 状态，但描述中明确指出，这个 JEP 将被添加到 JDK21 中。

JEP 草案 8277163，值对象（预览版），是由 Valhalla 项目赞助的一个 JEP 特性，提议创建价值对象——无身份标识的值类，指定其实例的行为。该草案与 JEP 401，原语类（预览版）相关，目前仍处于 Candidate 状态。

JEP 435，异步堆栈跟踪VM API，一种 JEP 类型的特性，提议定义一个有效的 API，用于收集堆栈跟踪信息，以便根据包含 Java 和本地堆栈帧信息的信号处理器进行分析。

JEP 401，原语类（预览版），在 Valhalla 项目的支持下，引入了开发人员声明的原语类——特殊类型的值类——如前面提到的值对象（预览版）JEP Draft 中所定义——定义了新的原语类型。

JEP 草案 8301034，密钥封装机制API，一种 JEP 类型的特性，提议：满足标准密钥封装机制（Key Encapsulation Mechanism，KEM）算法的实现；通过更高级别的安全协议满足 KEM 的用例；并且允许可插拔的 KEM 算法的 Java 或本地实现。该草案最近进行了更新，其中包括一项重大更改，即取消了 DerivedKeyParameterSpec 类，转而将字段放在 encapsulate(int from, int to, String algorithm) 方法的参数列表中。

JEP 草案 8283227，JDK源结构，一种信息类的 JEP，用于描述 JDK 源代码和 JDK 代码库中相关文件的总体布局和结构。该 JEP 提议帮助开发人员适应在 JDK9 中提供的 JEP 201，模块化源代码中所描述的源代码结构。

JEP 草案 8280389，ClassFile API，提议提供一个用于解析、生成和转换 Java 类文件的 API。该 JEP 最初将作为 JDK 中ASM（Java 字节码操作和分析框架）的内部替代品，并计划将其作为公共 API 开放出来。甲骨文（Oracle）的 Java 语言架构师Brian Goetz将 ASM 描述为“一个带有大量遗留包袱的旧代码库”，并提供了有关该草案将如何演进并最终取代 ASM 的背景信息。

JEP 草案 8278252，JDK打包和安装指南，一个信息型的 JEP，提议为 macOS、Linux 和 Windows 提供创建 JDK 安装程序的指南，以降低不同 JDK 提供程序在 JDK 安装之间发生冲突的风险。其目的是通过规范化安装目录名称、包名称和其他可能导致冲突的安装程序元素，在安装 JDK 更新版本时提升更好的用户体验。

我们预计甲骨文将会很快开始为 JDK 21 提供更多的额外 JEP。

原文链接：

https://www.infoq.com/news/2023/03/java-20-so-far/