随着 Java 11 的发布， Java 最终完成了到 OpenJDK 一等项目的过渡。使用专有 OracleJDK 二进制文件的日子已经结束了。对 Java 开放性和免费的关注自然而然将 Oracle 以外的公司的贡献带入到了聚光灯下。最近，InfoQ 采访了 Red Hat 中间件产品管理高级总监 Rich Sharples，讨论了 OpenJDK 和 Red Hat 的参与情况。

InfoQ：在很早之前，Red Hat 就一直是 OpenJDK 的贡献者。你能谈谈你和这个项目之间的历史渊源吗？

InfoQ：我们来谈谈目前的状况。目前看来，Red Hat 有多少工程师正在参与 OpenJDK 的工作（全职和兼职）？主要参与哪些方面的工作？

Sharples： 出于政策方面的考虑，我们不方便公开 Red Hat 在特定项目上的投入情况。Red Hat Java 平台团队首席工程师 Andrew Haley 多年来一直是 OpenJDK 管理委员会的成员，同时也是 AArch64 移植项目的负责人。此外，Andrew 还是 JDK 7 项目的负责人，并打算在 Oracle 支持周期结束后申请负责 OpenJDK 8 和 11 的开发。

InfoQ：在具体技术方面，你认为 Red Hat 在哪些领域做出了最大的贡献？哪些技术组件可以体现 Red Hat 的强大领导力？

Sharples： Red Hat 领导了 64 位 ARMv8 的移植，即 OpenJDK 的 AArch64 项目，并将它并入上游的 OpenJDK 项目中。目前，我们正在与 OpenJDK 社区合作开发一个新的超低停顿时间的垃圾回收器，名字叫作 Shenandoah，它处于 OpenJDK 主线之外——但在 Red Hat Enterprise Linux 7 中得到完整的支持。这项工作计划在 OpenJDK 12 中并入主线。

InfoQ：目前，OpenJDK 垃圾回收方面的情况非常有意思。例如，截止 JDK 11，G1 最终成为一个成熟的垃圾回收器。Red Hat 有 Shenandoah，而 Oracle 一直在开发 ZGC。你能评论一下 Red Hat 在 GC 方面的参与情况吗，特别是关于 G1？你如何对比 Shenandoah 和 ZGC？你能否估计一下 Red Hat 认为 Shenandoah 会在什么时候成为一个生产就绪的垃圾回收器？

Sharples： 目前，我们主要参与的仍然是 Shenandoah GC。此外，在 Hotspot 的 GC 接口开发方面（尽管对用户不可见）也进行了非常重要的协作，Red Hat 正积极参与其中。过去，GC 代码与 Hotspot 代码交杂在一起，但现在每个 GC 的代码都很好地分离出来了。Shenandoah 与 G1 共享了一些代码，所以需要做一些改进和 bug 修复。值得注意的是，G1 采用了最初出现在 Shenandoah 中的一些特性，例如多线程 Full GC，以及最近的空闲未提交堆（heap uncommit on idle）。ZGC 和 Shenandoah 的目标非常相似（减少收集大堆的停顿时间），但它们遵循的是非常不同的实现策略——Shenandoah 使用 Brooks Pointers，而 ZGC 使用彩色指针和多内存映射。ZGC 在吞吐量和停顿时间方面做得更好，而 Shenandoah 具有更好的人体工程学，这意味着它在一些恶劣的情况下（例如满堆或堆分配激增）会运行得更好。ZGC 不能（按照设计）使用压缩的 oops，这意味着它在中型（<32GB）的堆上有一定的弱势。此外，Shenandoah 在小堆上运行良好，这让它有可能会成为增长型应用程序的理想 GC，但并不保证会这样。据我们所知，Shenandoah 已经是 JDK-8u 发行版（Red Hat Enterprise Linux >= 7.5）的一部分。我们目前正在努力让 Shenandoah 进入上游（JDK 12）。如果我们做到了，它将成为一个实验性特性。我们现在还不敢说这个实验性标志什么时候将从上游 OpenJDK 发行版中移除。

InfoQ：显然，最近的一个重大新闻是 Red Hat 被 IBM 收购。这将给 Red Hat 与 OpenJDK 之间的关系带来什么样的影响？

Sharples： 关于与收购有关的内容请参阅我们发布的新闻和 Jim Whitehurst 的博文。

InfoQ：你认为 OpenJDK（以及 Java/ JVM 生态系统）最激动人心的部分是什么？你认为哪些技术是我们的读者在未来 12 到 18 个月内最应该关注的？

Sharples： Java 必须超越当前的位置，也就是作为大规模关键业务应用程序的可扩展语言运行时，并与更轻量、更灵活的语言和运行时展开竞争——特别是在内存占用和延迟非常敏感的云原生环境中。Java 社区继续在 JVM 层面进行创新。除此之外，Graal 和 Substrate VM 已经认识到，在容器和 DevOps 环境中，JVM 的平均运行寿命要短得多。单体应用程序一次在 JVM 上可以运行数月，而持续交付环境中的容器化 微服务 可能一次只运行数天或数小时，而在无服务器环境中，它们可能只运行几秒（甚至几毫秒）。值得注意的是，不仅仅是 JVM 令人感到兴奋，更广泛的 Java 生态系统也正极力追赶。除了优化 JVM 本身以及不断引入像 Thorntail 这样的新的轻量级和灵活的运行时之外，Eclipse MicroProfile 及其规范也有助于将开发传统单体应用程序的 Java EE 开发人员带入轻量级微服务领域。Red Hat，以及 Fabic8 Maven Plugin 和 Spring Cloud Kubernetes 等工具，一直在引领 Kubernetes、Istio 和 OpenShift 原生 Java 应用程序的开发。这极大简化了微服务架构，而在几年前，它们需要很多单独管理的独立基础设施服务。整个 Java 生态系统在持续快速地向前发展。我们也在考虑针对专门工作负载（如 AI 和机器学习）的芯片架构（如 ARM 和 GPU）和云架构的新元素，如边缘设备、网关、移动设备和可穿戴设备。

InfoQ：还有其他想对我们读者说的吗？

Sharples： 人们对 Java 兴趣程度从未如此强烈，Java 的未来也从未如此光明。

查看英文原文：