今年早期，在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社区。
原文链接：