Java 16 驾到！

Sharat Chander 发表于 2021 年 3 月 16 日

在 Twitter 上关注 OpenJDK

2020 年是 Java 令人难忘的一年，因为我们庆祝了它的 25 岁生日。经过二十多年的创新，Java 始终保持着：

  • 灵活性，通过适应不断变化的技术环境，同时保持平台独立性。
  • 可靠性，通过保持向后兼容性。
  • 高性能，通过加速创新而不牺牲安全性。

再加上 Java 能够一路提升平台的性能、稳定性和安全性，它仍然是全球开发者中最受欢迎的编程语言。根据 IDC 的最新报告“Java 迈入 25 周年”，全球超过 900 万开发者（占全职开发者的 69%）使用 Java，超过任何其他语言。

为了进一步证明 Java 的持续创新之路，Oracle 荣幸地宣布 Java 16 正式发布，这是六个月发布周期中的第七个功能版本。这种可预测性使开发者能够更容易地管理他们对创新的采用，这得益于稳定的预期变化流。

Chart showing number of features per release since Java 8


Java 16 现已发布！

Oracle 现在为所有开发者和企业提供 Java 16。根据 Oracle 重要补丁更新 (CPU) 时间表，Oracle JDK 16 将至少收到两个季度更新，然后是 Oracle JDK 17。Java 17 将于 2021 年 9 月正式发布，但抢先体验版本已在 jdk.java.net 上提供。

Oracle 再次以 Oracle OpenJDK 版本的形式提供 Java 16，该版本使用带有类路径异常的开源 GNU 通用公共许可证 v2 (GPLv2+CPE)，同时也根据 商业许可证提供给那些将 Oracle JDK 版本作为 Oracle 产品或服务的一部分使用的用户，或者那些希望能够获得商业支持的用户。


携手共进，Java 16

与之前的版本类似，我们继续赞赏 OpenJDK 社区的许多个人和组织对 Java 16 做出的贡献——我们共同构建 Java！

JDK 16 修复比率

多年来，JDK 的总体变化率基本保持不变，但在六个月的发布周期下，生产就绪的创新交付速度得到了极大提高。

不再是每隔几年就在一个大型主要版本中提供数万个修复和大约一百个 JDK 增强提案 (JEP)，而是在更易于管理、可预测的六个月时间表内以较小的功能版本交付增强功能。这些变化的范围可以从一项重要功能到小的改进，再到例行维护、错误修复和文档改进。每个更改都表示为 JDK 错误系统 中单个问题的单个提交。

在 Java 16 中标记为已修复的 1,897 个问题中，1,397 个是由 Oracle 员工完成的，而 500 个是由个人开发者和其他组织的开发者贡献的。通过查看问题并整理来自受让人的组织数据，可以得出以下关于赞助 Java 16 修复开发的组织图表

Graph showing the number of fixes per organization

Oracle 要感谢 ARM、SAP、Red Hat 和腾讯等组织的开发者做出的显著贡献。我们还要感谢来自 Ampere Computing、Bellsoft、DataDog、Microdoc 等规模较小的组织以及独立开发者的贡献，他们共同贡献了 Java 16 中 3% 的修复。

我们同样感谢许多经验丰富的开发者对提议的更改进行了审查，感谢早期采用者试用了早期访问版本并报告了问题，感谢那些在 OpenJDK 邮件列表中提供反馈的专业人士。

以下个人对构建质量提供了宝贵的反馈，记录了高质量的错误或提供了频繁的更新

  • Jaikiran Pai (Apache Ant)
  • Gary Gregory (Apache Commons)
  • Uwe Schindler (Apache Lucene)
  • Robert Scholte (Apache Maven)
  • Mark Thomas (Apache Tomcat)
  • Enrico Olivelli (Apache Zookeeper)
  • Rafale Winterhalter (Byte Buddy)
  • Peter Karich (Graph Hopper)
  • Evgeny Mandikov (JaCoCo)
  • Marc Hoffman (JaCoCo)
  • Vincent Privat (JOSM)
  • Christian Stein (JUnit 5)
  • David Karnok (RxJava)

此外，通过 质量拓展计划，我们要感谢以下 FOSS 项目和个人，他们对 Java 16 早期访问版本的测试提供了出色的反馈，帮助提高了版本的质量。

  • Apache Ant
  • Apache Derby (Rich Hillegas)
  • Apache Lucene
  • Apache Maven
  • Apache Tomcat
  • Apache Wicket (Martin Grigorov)
  • Apache ZooKeeper
  • Eclipse Collections (Nikhil Nanivadekar)
  • eo-yaml (Mihai Andronache)
  • FXGL (Almas Baimagambetov)
  • FXyz (Sean Phillips)
  • Java Katas (Chandra Guntur)
  • GraphHopper
  • Hibernate ORM
  • Hibernate Validator
  • Hibernate Search
  • Hibernate Reactive (Sanne Grinovero & Yoann Rodiere)
  • JobRunr (Ronald Dehuysser)
  • jOOQ (Lukas Eder)
  • MyBatis (Iwao Ave)
  • Micrometer (Tommy Ludwig)
  • RxJava
  • Sejda
  • PDFsam (Andrea Vacondio)


Java 16 的新功能

除了数千项性能、稳定性和安全更新之外，Java 16 还为用户提供了 十七项主要增强/更改（称为 JDK 增强提案 - JEP），包括三个孵化器模块和一个预览功能。

一些增强功能是在 孵化器模块 中引入的，这是一种将非最终 API 和非最终工具交到开发者手中的方法，允许用户提供反馈，最终可以提高 Java 平台的质量。

类似地，一些增强功能是作为 预览功能 引入的，这些功能是 Java SE 平台的语言或 VM 功能，它们已完全指定、完全实现，但并非永久性的。它们在 JDK 功能版本中提供，以根据实际使用情况征求开发者反馈，这可能会导致它们在未来的版本中成为永久性的。这为用户提供了及时提供反馈的机会，也让工具供应商有机会在大多数 Java 开发者在生产环境中使用该功能之前构建对该功能的支持。

Java 16 中提供的 17 个 JEP 被分为六个不同的类别

新的语言功能

JEP 394 instanceof 的模式匹配

模式匹配最初在 Java 14 中作为预览功能引入，并在 Java 15 中再次引入，它通过 instanceof 运算符的模式匹配增强了 Java 编程语言。

模式匹配允许以更简洁、更安全的方式表达程序中的常见逻辑，即从对象中条件提取组件。

JEP 395 记录

记录也是在 Java 14 中作为预览功能首次引入，并在 Java 15 中再次引入，它提供了一种紧凑的语法来声明类，这些类是浅层不可变数据的透明持有者。这将显著减少这些类的冗长度，并提高代码的可读性和可维护性。

JVM 改进

JEP 376 ZGC 并发线程处理

JEP 376 将 ZGC 线程堆栈处理从安全点移至并发阶段，即使在大型堆上，也允许在 GC 安全点内进行亚毫秒级暂停。消除 ZGC 垃圾收集器中的最终延迟源将大大提高此版本及后续版本中应用程序的性能和效率。

JEP 387 弹性元空间

此功能将未使用的 HotSpot 类元数据（即*元空间*）内存更及时地返回给操作系统，从而减少元空间占用空间。具有繁重的类加载和卸载活动的应用程序可能会累积大量未使用空间。新方案以更小的块分配元空间内存，减少类加载器开销和碎片化。它通过将未使用的元空间内存返回给操作系统来提高弹性，从而提高应用程序性能并减少内存利用率。

新工具和库

JEP 380 Unix 域套接字通道

Unix 域套接字长期以来一直是大多数 Unix 平台的一项功能，现在 Windows 10 和 Windows Server 2019 也支持该功能。此功能为 java.nio.channels 包中的套接字通道和服务器套接字通道 API 添加了 Unix 域 (AF_UNIX) 套接字支持。它扩展了继承的通道机制，以支持 Unix 域套接字通道和服务器套接字通道。Unix 域套接字用于同一主机上的进程间通信 (IPC)。它们在大多数方面与 TCP/IP 套接字类似，不同之处在于它们通过文件系统路径名而不是 Internet 协议 (IP) 地址和端口号寻址。对于本地进程间通信，Unix 域套接字比 TCP/IP 回环连接更安全、更高效。

JEP 392 打包工具

此功能最初是在 Java 14 中作为孵化器模块引入的。此工具允许打包自包含的 Java 应用程序。它支持本机打包格式，为最终用户提供自然的安装体验。这些格式包括 Windows 上的 msi 和 exe、macOS 上的 pkg 和 dmg 以及 Linux 上的 deb 和 rpm。它还允许在打包时指定启动时参数，并且可以通过命令行直接调用，也可以通过 ToolProvider API 以编程方式调用。请注意，jpackage 模块的名称从 jdk.incubator.jpackage 更改为 jdk.jpackage。这将改善最终用户安装应用程序时的体验，并简化使用“应用商店”模型的部署。

面向未来的工作

JEP 390 基于值的类的警告

此功能将基本类型包装类（java.lang.Integer、java.lang.Double 等）指定为基于值的（类似于 java.util.Optional 和 java.time.LocalDateTime），并向其构造函数添加 forRemoval，这些构造函数自 JDK 9 起已弃用，从而提示新的警告。它提供有关在 Java 平台中尝试对任何基于值的类的实例进行同步时的不当行为的警告。

许多流行的开源项目已经通过从其源代码中删除包装器构造函数调用来响应 Java 9 的弃用警告，考虑到“弃用以供删除”警告的紧迫性，我们可以预期还会有更多项目这样做。

JEP 396 默认情况下强封装 JDK 内部结构

此功能默认情况下强封装 JDK 的所有内部元素，但关键的内部 API（如 sun.misc.Unsafe）除外。使用早期版本成功编译的代码访问 JDK 的内部 API 可能不再默认有效。此更改旨在鼓励开发人员从使用内部元素迁移到使用标准 API，以便他们及其用户都可以轻松升级到未来的 Java 版本。强封装由启动器选项 -–illegal-access 控制，对于 JDK 9 到 JDK 15，默认值为 warning，从 JDK 16 开始，默认值为 deny。目前仍然可以使用单个命令行选项放宽所有包的封装，但在将来，只有使用 –add-opens 打开特定包才会有效。

孵化器和预览功能

JEP 338 向量 API（孵化器）

此孵化器 API 提供了用于表达向量计算的 API 的初始迭代，这些计算在运行时可靠地编译为支持的 CPU 架构上的最佳向量硬件指令，从而实现优于等效标量计算的性能。它允许利用大多数现代 CPU 上提供的单指令多数据 (SIMD) 指令。尽管 HotSpot 支持自动向量化，但可转换标量运算集有限，并且容易受到代码更改的影响。此 API 将允许开发人员轻松地在 Java 中编写可移植且高性能的向量算法。

JEP 389 外部链接器 API（孵化器）

此孵化器 API 提供对本机代码的静态类型化、纯 Java 访问。此 API 将大大简化原本复杂且容易出错的绑定到本机库的过程。自 Java 1.1 以来，Java 一直通过 Java 本机接口 (JNI) 支持本机方法调用，但这既困难又脆弱。Java 开发人员应该能够（大部分）只使用任何被认为对特定任务有用的本机库。它还提供外部函数支持，而无需任何中间 JNI 粘合代码。

JEP 393 外部内存访问 API（第三个孵化器）

此 API 最初在 Java 14 和 Java 15 中作为孵化器 API 引入，它允许 Java 程序安全有效地对各种外部内存（例如，本机内存、持久内存、托管堆内存等）进行操作。它还为外部链接器 API 提供了基础。

JEP 397 密封类（第二个预览版）

此预览功能限制了哪些其他类或接口可以扩展或实现它们。它允许类或接口的作者控制哪些代码负责实现它。此外，它提供了一种比访问修饰符更具声明性的方式来限制超类的使用。并且，它通过支持模式的详尽分析来支持模式匹配的未来方向。

提高 OpenJDK 开发人员的生产力

其余更改对 Java 开发人员（使用 Java 编写和运行应用程序的人员）不可见，而仅对 Java 开发人员（在 OpenJDK 上工作的人员）可见。

JEP 347 启用 C++14 语言功能（在 JDK 源代码中）
这允许在 JDK C++ 源代码中使用 C++14 语言功能，并提供有关哪些功能可以在 HotSpot 代码中使用的具体指导。在 JDK 15 之前，JDK 中的 C++ 代码使用的语言功能仅限于 C++98/03 语言标准。它需要更新各种平台编译器的最低可接受版本

JEP 357 从 Mercurial 迁移到 Git，JEP 369 迁移到 GitHub
这些 JEP 将 OpenJDK 社区的源代码存储库从 Mercurial (hg) 迁移到 Git，并将它们托管在 GitHub 上，用于 JDK 11 及更高版本。迁移包括将 jcheck、webrev 和 defpath 等工具更新为 Git。Git 减少了元数据的大小（大约是大小的 ¼），从而节省了本地磁盘空间并减少了克隆时间。现代工具与 Git 的集成比 Mercurial 更好。OpenJDK Git 存储库现在位于 https://github.com/openjdk。

JEP 386 Alpine Linux 端口，JEP 388 Windows/AArch64 端口
这些 JEP 的重点不是移植工作本身（这已经完成），而是将它们集成到 JDK 主线存储库中。JEP 386 将 JDK 移植到 Alpine Linux 以及其他使用 musl 作为其主要 C 库的发行版，包括 x64 和 AArch64。此外，JEP 388 将 JDK 移植到 Windows AArch 64 (ARM64)。


工具支持

当前的工具支持有助于提高开发人员的生产力。在 Java 16 中，我们继续欢迎领先的 IDE 供应商的努力，他们的工具解决方案为开发人员提供了对当前 Java 版本的支持。开发人员可以使用以下 IDE 获得 Java 16 支持

Java 仍然是软件程序员首选的第一编程语言。正如 Java 16 按时交付改进所证明的那样，通过持续的周密计划和生态系统参与，Java 平台完全有能力在云中进行现代化开发和增长。

继续通过以下方式了解最新消息和更新

  • 访问 Inside.Java（Oracle Java 团队的新闻和观点）
  • 收听 Inside.Java 播客（由 Oracle 的 Java 制作者直接为您带来的 Java 开发人员节目。我们将讨论语言、JVM、OpenJDK、平台安全、Loom 和 Panama 等创新项目，以及介于两者之间的所有内容）。
  • 加入 OpenJDK 邮件列表（了解您最喜欢的 OpenJDK 项目进度的最佳场所）。