InfoQ 访谈:Java 的现状和未来

阅读数:5741 2019 年 7 月 2 日

今年早期,在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 发布的新节奏,出发点是稳定推出实现的新特性,使得用户的变更速度跟上甚至超越原有的发布时间表。

目前几个大项目正在推进中,例如ValhallaLoomPanama。这些项目一旦发布,版本中将包含许多新特性。重在保持 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

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

Ti 2019 年 07 月 02 日 12:26 0 回复
可别搞碎片化了
没有更多了