InfoQ 访谈：Java 的现状和未来

今年早期，在Azul Systems的技术博客上，公司技术副总 Simon Ritter就Java 12的新特性发表了一篇文章。针对前期报道“JAVA 13 进入特性冻结阶段”，InfoQ 采访了 Ritter，内容涉及 Java 12 和 13 版本，以及 Azul 在 Java 新版本推出后所采取的行动。

InfoQ：我们首先探讨一下 Azul 的产品吧。你们提供两个独立的 JDK 产品，一个是自身的 OpenJDK 发行版 Zulu，另一个是高性能专用 JVM Zing。对于企业市场而言，这两个产品有何差异？

Simon Ritter：Zing 是我们的商业 JVM 产品，目标是优化对低延迟和高吞吐量有需求的 Java 应用性能。该市场针对的是在工作负载上具有很高要求的用户。现有的垃圾回收机制存在非确定性的本质，无法处理此类工作负载

对于交易系统或网页广告注入等应用，它们无法容忍垃圾回收的暂停时间，而暂停时长取决于堆的规模。此类应用需要新的方法。Zing 是提供了一种永不暂停的回收器。

Zulu 是我们面向那些有意替代 Oracle JDK 的用户而构建的 OpenJDK。Oracle 自 JDK 11 开始，更改了 Java 的发行许可证。这意味着许多依赖免费更新的用户，现在必须面对付费使用 Oracle 或使用其他发行版的问题。Zulu 企业版提供完整的 SLA 支持，以非常合理的成本提供更新。它适用于那些不受支持的免费版本无法适合自身需求的用户。

InfoQ：确认一下，使用 GPL 许可的 Zulu 二进制文件是否支持自由重用？是否无需购买支持许可即可从 Azul 网站下载安装运行文件？

Ritter：当然。我们提供了两个版本的 Zulu。其中，社区版可以从我们的网站免费下载，并自由使用。而企业版是受商业支持的版本，支持更新的 SLA，并提供解决问题的支持渠道。

InfoQ： 你们也为嵌入式系统提供了一款产品。对于你来说，它是如何融入企业整体发展的？

Ritter：我们还有第三条产品线，即 Zulu Embedded。该产品不仅针对智能电表、车载娱乐设备等真正的嵌入式系统，而且适用于那些希望将 JDK 与其应用代码绑定以简化安装的用户。

InfoQ：你能否介绍一下 Zing（Azul 专有 JVM）的路线图？Zing 多年来一直提供独具特色的 C4 垃圾回收器。该回收器是否正受到 OpenJDK 提供的新回收器的威胁（例如，ZGC 和 Shenandoah 等）？企业如何应对不断变化的 JVM 市场？

Ritter：从根本上说，我们一直在寻求可解决 JVM 相关性能问题的解决方案。尽管受控的运行时环境非常适于简化开发和部署，但 JIT 编译器在工作中依然存在垃圾回收暂停和应用预热时间等不足。

为解决垃圾回收问题，我们着手开发了 C4（即“连续并发压缩式回收器”，Continuously Concurrent Compacting Collector）。 尽管这些年 C4 做了一些改进，但通过加载值屏障（value barrier）和 LVB 的基本方法并未发生变化。

Shenandoah 有别于 C4，它采用了不同的方法，当前只使用了单一生成堆。而 ZGC 从方法上看更类似于 Zing，并不能完全避免垃圾回收暂停。上述两种回收器仍处于试验阶段，因此，我并不认为很多客户会在不久的将来将它们部署在生产环境中，尤其是那些寻求严格 SLA 的客户。我们特别关注业界相关产品动态。

InfoQ：能介绍一下其它 JVM 子系统吗？

Ritter：就在最近，我们将关注点转向其它 JVM 部分。我们使用自身基于 LLVM 编译器的 Falcon JIT，替代了 C2 JIT，这带来了很大的性能改进，特别是在能以更好的方式处理向量等方面。为降低预热时间，我们开发了 ReadyNow!。该技术对运行中应用做快照，进而使用快照加载并初始化类，并在到达主入口点之前编译方法。

我们最新开发的特性是 Compile Stashing。它可从应用运行过程中保存编译代码，并对代码做高效缓存，降低了使用 ReadyNow!所需的编译量。在 JVM 规格说明中，对 JVM 启动阶段可做和不可做的事情给出了非常详细的说明。这使得我们推出的全新理念可以通过 TCK 挑战。

InfoQ：这些新技术是否会开源？未来是否会考虑开源？

Ritter：作为商业产品，我们并没有对代码采用开源许可。未来是否会做出改变，尚需拭目以待！

InfoQ：Azul 对非 LTS 版本 Java 有哪些经验？用户是否的确会在自己的生产系统中使用它们？?

Ritter：我在很多大会上谈及此问题，并现场调查听众在生产环境中使用的 JDK 版本情况。很多人依然使用 JDK 8，但越来越多的人正在迁移到 JDK 11。从现场的举手情况看，迁移到 JDK 11 的用户比例大概在 10-15%。这样的非正式调研显示，很少有用户使用非 LTS 版本。

InfoQ：我们来谈谈 Java 12，特别是新的 Switch 表达式特性。您认为该特性的可用性如何？据您的观察，是否有开发人员采用该特性？

Ritter：我认为 Switch 表达式是一个很有用的功能，它澄清了 Java 语言中的一处模糊地带。由于 Java 的主要语法都源自于 C 语言，因此 Java 必须处理类似于 switch 的语句，以不同的方式来实现，进一步对其进行简化。

必须区分单个 case 表达式和不使用 break 就会出现问题，这即繁琐又容易出错。将 switch 作为表达式（就像一条语句一样）是很好的一种做法。因为这样只需要在代码中做一次赋值，从而消除可能的错误来源。

不同于开发人员对 lambda 和 stream 特性赞誉有加，至今我尚未听到 Switch 表达式的任何意见。这是因为该特性仅在 JDK 12 中提供了，并且仅是作为预览特性，我怀疑在下一个 LTS 版本给出之前，该特性的使用都会很有限。

InfoQ：能整体介绍一下预览特性（Preview Features）机制吗？其实用性是否得到验证？是否存在一些问题？

Ritter：我认为这个机制很有效。Switch 表达式是首个以预览方式添加的功能，大家已体验到该特性的优点。为维持旧版本的外观，JDK 12 版本使用了带值的 break 语句。

在编码中，不能将数值作为标签使用。如果一并使用跳出循环到标签处和 switch 语句表达式，同样会造成混淆。考虑到代码清晰化，在 JDK 13 中已决定改为使用 yield（即http://Java的现状和未来：Azul System 访谈">JEP 354）。如果某个特性并未作为预览功能，我们就难以搞清楚是否可以采用上述方式做出改进，因为该语法已经包含在 Java SE 语言规范中。

InfoQ：您能对比一下语言的预览特性与 HTTP/2 支持等孵化器 API（Incubator API）这两者吗？ 在您看来，两者之间存在哪些不同？

Ritter：孵化器模块直接应用于 API，而预览语言功能主要涉及语言的语法。除此以外，二者毫无二致。二者都支持无需修改规范而添加新功能。可根据必要的反馈直接修改它们，甚至完全删除，无需更改规范。二者对于 Java 平台的深远发展是颇有裨益的。

在我个人看来，尽早引入上述做法会使我们避免一些问题。

InfoQ：Java 13 即将进入功能冻结阶段。您对该版本有何看法？尽管从现在开始到 9 月份 Java 13 的 GA 发布之间，不太可能再做出多少有意义地改进。

Ritter：JDK 13 将同样是一个并未包含许多功能改进的版本。目前看来，其中只添加了五个 JEP 计划。开发人员不太可能第一时间就转向使用此版本。JDK 发布的新节奏，出发点是稳定推出实现的新特性，使得用户的变更速度跟上甚至超越原有的发布时间表。

目前几个大项目正在推进中，例如Valhalla、Loom和Panama。这些项目一旦发布，版本中将包含许多新特性。重在保持 Java 的持续发展，避免停滞不前。

InfoQ：再聊聊“文本块”（Text Blocks，先前称为“多行字符串”，multi-line string）特性。该特性是否可作为沃德勒定律（Wadler’s Law）的一个实际体现？

Ritter：是的。有趣的是，似乎总是一些最小的特性反而得到更多的讨论。Java 过去曾出现过多次出现掉链子的问题。

大量实例表明，多行字符串有助于简化某些语法。但是对于我这样从 JDK 1.0 就开始使用 Java 编程的人而言，确实需要使用此特性的情况屈指可数。

InfoQ：最近 OpenJDK 邮件列表讨论热烈。在一些话题中，例如 OpenJDK 的 Docker 镜像、Debian 项目如何为其版本获取源代码并构建二进制文件等，都有 Azul 工作人员的参与，尤其是 Gil Tene。您能否概要阐述一下上述问题？您是否认为这些问题已经得到了令人满意的解决？

Ritter：被 Gil 描述为“JDK 乱炖”（mystery meat JDKs）的问题，是与滥用 JDK 二进制文件的版本字符串有关。一些可用的二进制文件中具有更新编号，用于尚未发布的下次更新。

由此，问题在于用户是否信任 JDK 8u212 事实上已经包含了指定的更新。JDK 二进制文件具有多个来源，用户显然需要确认他们获得了自身认为需获得的版本。在确定更新问题已得到解决之前，我们需要了解该机制在未来的更新中的工作方式。

InfoQ：鉴于 OpenJDK 8 已不再受 Oracle 管理，现在一项可能的举措是反向移植（backport）那些 Oracle 曾不愿意采用的功能或补丁。其中最突出的一项，就是 Azul 深度参与的 Java Flight Recorder（JFR）向 OpenJDK 8 的反向移植。您能解释一下反向移植的重要性、Azul 的参与情况，以及相关补丁的最新情况吗？

Ritter：Flight Recorder 提供一组需构建到 JVM 中的功能，它支持收集 JVM 和应用执行情况相关的详细度量。这些数据将被任务控制（Mission Control）应用使用。任务控制应用由 Oracle 开源提供，作为 Oracle JDK 和 OpenJDK 间融合的组成部分。

Oracle JDK 已将 Flight Recorder 集成到 JDK 8 中。因此，Flight Recorder 仍然是一个商业功能，需要具有付费许可才能在生产环境中使用。现在 Oracle JDK 8 已经终止免费公开更新（至少对于商业用户而言如此），人们正迁移到没有 Flight Recorder 的 OpenJDK 8 版本。

正如你所说的，Azul 一直致力于将 Flight Recorder 后向移植到 OpenJDK 8 中。目前，Flight Recorder 已包含在我们的 Zulu 8 二进制文件中。我们正与其他 OpenJDK 贡献者合作，使其成为OpenJDK源代码的组成部分。

InfoQ：Azul 是否还参与了其它 OpenJDK 项目，或是对一些启动项目有兴趣？

Ritter：Azul 深度参与了 Java 生态系统的方方面面。自 2011 年以来，我们就任 JCP 执行委员会成员；自 Java SE 9 发布以来，我们就是 Java SE 专家组成员。我们的工程师 Andrew Brygin 是 OpenJDK 的项目牵头人。此外，我们正持续对 OpenJDK 项目做出贡献，例如 JEP 285“旋转-等待提示”（Spin-Wait Hints）。我们将继续通过 JUG 访问、资助 AdoptOpenJDK 活动等方式支持 OpenJDK，乃至更大范围的 Java 社区。

原文链接：

Azul Systems Discuss Java’s Present and Future