背景

定于9月推出的Java21计划现在包括一个关键封装机制API和32位Windows端口的弃用。
在这里插入图片描述
Java开发工具包（JDK）21将于9月作为Oracle标准Java实现的下一个长期支持版本，现在有13个功能被正式提出，最近几天又增加了两个功能。

最新的提议包括密钥封装机制（KEM）API和32位x86 Windows端口的弃用。本月早些时候，还添加了其他三个功能，即代Shenandoah垃圾收集器、未命名类和实例主方法以及未命名模式和变量。

这五个建议结合了3月和4月提出的八个功能：一代ZGC（Z垃圾收集器）、记录模式、switch表达式和语句的模式匹配、向量API、序列化集合、虚拟线程、字符串模板预览以及外部函数和内存API的第三个预览。另外，JDK 21还将改变Windows上网络接口的网络名称分配方式。

GPL下的早期访问二进制文件可在jdk.java.net上获得。Oracle每六个月发布一次标准java的新版本，最近的jdk 20已于3月21日发布。到目前为止，JDK 21的具体建议包括：

密钥封装机制API，一种通过公共加密来保护对称密钥的加密技术。该提案的一个目标是使应用程序能够使用KEM算法，如RSA密钥封装机制（RSA-KEM）、椭圆曲线集成加密方案（ECIES），以及美国国家标准与技术研究所（NIST）后量子密码学标准化过程的候选算法。另一个目标是使KEM能够在更高级别的协议（如传输层安全性（TLS））和加密方案（如混合公钥加密（HPKE））中使用。此外，安全提供商将能够在Java代码或本机代码中实现KEM算法，并包括在RFC 9180中定义的Diffie-Hellman KEM（DHKEM）的实现。
不推荐删除Windows 32位x86端口，目标是在将来的版本中删除它。该提案旨在更新生成系统，以便在尝试为Windows 32位x86配置生成时发出错误消息。该消息将通过新的配置选项被抑制。此外，计划将端口和相关端口特定功能标记为不推荐在相关文档中删除。该提案指出，Windows 10是最后一款支持32位操作的Windows操作系统，将于2025年10月停止使用。
Generational Shenandoah，一项旨在增强Shenandoh GC的提案，具有实验性的代收集能力，以提高可持续吞吐量、负载峰值弹性和内存利用率。该提案的主要目标是在不打破非世代Shenandoah的情况下提供一种实验性的世代模式，目的是在未来的版本中使世代模式成为默认模式。其他目标包括在不牺牲低GC暂停的情况下减少持续的内存占用，减少CPU和功耗，保持高吞吐量，以及继续支持压缩对象指针。该提案最初将支持x64和AArch64，并随着实验模式的发展而增加对其他指令集的支持。它的目标不是取代非世代的Shenandoah，它将继续作为默认的操作模式，其性能或功能不会倒退。提高每一个可以想象的工作量的性能也不是一个目标。
预览未命名的类和实例主方法，以发展语言，使学生能够编写他们的第一个Java程序，而无需理解为大型程序设计的语言功能。学生们可以为单类程序编写精简的声明，而不是使用单独的Java方言，然后随着技能的发展，无缝地扩展程序以使用更高级的功能。其目的是为Java提供一个平滑的入口。
未命名模式和变量的预览，以使用未命名的模式和未命名的变量增强语言。未命名的模式匹配记录组件，而不说明组件的名称或类型，而未命名的变量可以初始化但不能使用。两者都用下划线字符_表示。该建议旨在通过消除不必要的嵌套模式来提高记录模式的可读性，并通过识别必须声明但不会使用的变量来提高所有代码的可维护性。
Generational ZGC旨在通过扩展ZGC来为新对象和旧对象保持独立的生成，从而提高应用程序性能。年轻的物体往往英年早逝，保持不同的世代将使ZGC能够更频繁地收集它们。使用世代ZGC运行的应用程序应该看到以下好处：更低的分配停滞风险、更低的堆内存开销和更低的垃圾收集CPU开销。与非世代ZGC相比，这些好处应该不会显著降低吞吐量。
JDK19和JDK20中预览的记录模式将解构记录值。可以嵌套记录模式和类型模式，以实现强大、声明性和可组合形式的数据导航和处理。该提案的目标包括扩展模式匹配以销毁记录类的实例，并添加嵌套模式，从而实现更可组合的数据查询。此功能与交换机的模式匹配共同发展。当前JEP（JDK Enhancement Proposal）中的记录模式建议在持续的经验和反馈的基础上进一步完善该功能。除了小的编辑更改外，自第二次预览以来的主要更改是删除了对出现在增强的for语句标题中的记录模式的支持。该功能可能会在未来的JEP中重新提出。
switch的模式匹配使switch表达式或语句能够针对多个模式进行测试，每个模式都有特定的操作，因此可以安全简洁地表达复杂的面向数据的查询。这个特性最初是在JDK17中提出的，后来在JDK18、JDK19和JDK20中进行了改进。它将在JDK 21中最终确定，并根据反馈和经验进行进一步改进。与以前的JEP相比，主要的变化是删除了带括号的模式，并允许使用限定的枚举常量，如带有开关表达式和语句的case常量。目标包括通过允许模式出现在case标签中来扩展switch表达式和语句的表达性和适用性，允许在需要时放松switch的历史null敌意，并通过要求模式switch语句覆盖所有潜在输入值来提高switch语句的安全性。另一个目标是确保现有的switch表达式和语句在没有任何更改的情况下继续编译，并以相同的语义执行。
Vector API的第六个孵化器，用于表达向量计算，这些计算在运行时可靠地编译为支持的CPU体系结构上的最优向量指令，实现优于等效标量计算的性能。这之前已经在JDK16到JDK20中进行了培育。最新版本包括性能增强和错误修复。该提案的目标包括清晰简洁，与平台无关，并在x64和AArch64架构上提供可靠的运行时编译和性能。其他目标包括优雅的降级，当矢量计算在运行时不能完全表示为矢量指令序列时，以及与Project Valhalla保持一致。
外部函数和内存API使Java程序能够与Java运行时之外的代码和数据进行互操作。通过有效调用外部函数和安全访问外部内存，此预览API使Java程序能够调用本机库并处理本机数据，而不会出现JNI（Java native Interface）的脆弱性和危险性。API之前在上个月首次亮相的JDK 20和2022年9月发布的JDK 19中进行了预览。最新预览中的改进包括使用新元素来取消引用地址布局的增强布局路径、对Arena接口中本地段的生存期的集中管理、回退本地链接器实现以及删除VaList。该提案的目标包括易用性、性能、通用性和安全性。在这个API之上重新实现JNI或以任何方式更改JNI都不是我们的目标。
虚拟线程是轻量级线程，承诺“显著”减少编写、维护和观察高吞吐量并发应用程序的工作量。该计划的目标包括使以简单线程请求方式编写的服务器应用程序能够以接近最佳的硬件利用率进行扩展，使使用lang.thread API的现有代码能够采用变化最小的虚拟线程，并使用当前JDK工具轻松调试和分析虚拟线程。之前在JDK20和JDK19中预览过，虚拟线程将在JDK21中最终确定。有了JDK21，虚拟线程现在一直支持线程本地变量，这使得不可能创建没有这些变量的虚拟线程。对线程本地变量的有保证的支持确保了更多的现有库可以与虚拟线程一起使用，并有助于迁移面向任务的代码以使用虚拟线程。
序列集合引入了接口来表示具有定义的相遇顺序的集合。每个集合都有定义明确的第一和第二元素，依此类推，直到最后一个元素。提供了统一的API来接受第一个和最后一个元素，并以相反的顺序处理元素。该提议的动机是Java的集合框架缺乏一种集合类型来表示具有定义的相遇顺序的元素序列。它还缺乏一套适用于这些集合的统一操作。这些差距一直是一个问题，也是投诉的根源。该提案要求定义集合、集合和映射的排序接口，并将其改造为现有的集合类型层次结构。所有这些新方法都有默认实现。
字符串模板作为预览功能出现，通过将文本与嵌入的表达式和处理器耦合以产生专门的结果，来补充Java现有的字符串文本和文本块。此语言功能和API旨在简化Java程序的编写，使其易于表达包含运行时计算的值的字符串。它承诺增强表达式的可读性，提高程序安全性，保持灵活性，并简化接受用非Java语言编写的字符串的API的使用。实现从结合文字文本和嵌入表达式派生的非字符串表达式的开发也是一个目标。