展望 Java SE 7 和 8:Oracle Java 语言架构师 Brian Goetz 访谈

   
作者:Janice J. Heiss  
我们邀请了 Oracle 的 Java 语言架构师 Brian Goetz,请他谈谈对于并发性、Java SE 7 和 8、
Java 虚拟机 (JVM) 发展等方面的看法。

2011 年 1 月发布

Java 语言架构师 Brian Goetz
Java 语言架构师 Brian Goetz
 

在对 Java 平台的认识方面,很少有人的思路像 Oracle 的 Java 语言架构师 Brian Goetz 一样深远。他发表了 80 多篇有关最佳实践、平台内幕和并发编程等主题的文章,他是 2006 年 Jolt 奖入围者之一、2006 年 JavaOne 大会最畅销图书《Java Concurrency in Practice》的主要作者。他于 2006 年 8 月加入 Sun Microsystems,之前是一名软件顾问,除了撰写有关 Java 技术的文章之外,还经常在各种会议上发表演讲并演示线程、Java 编程语言内存模型、垃圾回收、Java 技术性能解密以及其他主题。

2006 年至 2010 年在 Sun 任职期间,Brian 参与了多个项目,包括担任 JavaFX Script 编译器的架构师和 Java Warehouse 的架构师。加入 Oracle 之后,他担任 Java 语言架构师一职。他是 Lambda 项目的领导者,此项目是 Java Platform, Standard Edition (Java SE) 8 的组成部分,将为 Java 语言提供闭包和相关语言特性,此外还会升级核心 Java 库,以便更轻松地表示集合的并行计算。Lambda 还新增了虚拟扩展方法,这解决了一个由来已久的问题,即在定义了接口之后,开发人员无法在不破坏现有实现的前提下添加新方法。

我们与他进行了面对面的交流,了解他对于并发性、Java SE 7 和 8、Java 虚拟机 (JVM) 发展以及其他方面的看法。

问:我向许多领先的 Java 开发人员引述了您在 2007 年 3 月的访谈中说过的一句话:“通常,在 Java 应用程序中编写高速代码的方法就是编写傻瓜代码 — 直观、干净、遵从最明显的面向对象原则的代码。这是由动态编译器的本质决定的,它是一个庞大的模式匹配引擎。编译器是由人编写的,而人要受到计划和时间预算的限制,因此编译器开发人员的工作重心往往放在最常见的代码模式上,因为他们能够从中获得最大收益。”

尽管大多数开发人员都强烈赞同您的看法,但有两位 Java Champion 对此提出了中肯的意见。Matjaz Juric 注意到,服务器和计算机速度的提升使得代码执行速度逐渐不再成为问题,因此您的观点已经不再像过去一样有力。Yakov Fain 认为,如果简单修改代码能获得更好的效果,那么就应该这么做,而不必担心其他开发人员能否理解。他提到为 Java 开发人员举行的一次研讨会,开发人员们给他的感觉是实现 MVC 已经成为一个目的。他坚持认为,设计模式的使用不应成为一种教条。您对此作何感想?

答:我认为这两位开发人员实际上都没有直接回应我的观点,因此请允许我阐明我的观点。我们都知道,假定其他条件相同,干净的代码总是优于脏代码。我的论点在于编写脏代码的最常见理由就是所实现的性能好处,但遗憾的是,大多数冠以性能之名的代码甚至不具备预期的性能效果,因此往往适得其反。Matjaz Juric 的观察只是进一步证实了这种观点,在很多情况下,在某种程度上由于硬件速度快速提高,对性能的提高不再作为业务需求,因而人们不再为此付出努力。

Yakov 的观点在一定程度上是合理的 — 总是会存在一些情有可原的情况,使得“正确”的做法不一定正确。当然,必须依靠经验来了解突破常规的时机。如果确实获得了“更好的效果”,那么就应该坚持自己的做法。但在确定效果“良好与否”之前,您需要考虑未来的维护成本和故障风险。(如果您决定取消办公大楼的保险单,那么每月的盈亏报表可能看似获得了更好的结果,但仅限于办公大楼没有发生火灾的月份。)

 
“JSR-292,也就是所谓的“InvokeDynamic”JSR,让我倍感兴奋。JSR-292 的重点在于识别 JVM 架构中与 Java 语言联系过于紧密的方面,使之更为通用,从而消除 JVM 中许多非 Java 语言的难题,例如 JRuby、Jython、JavaScript、Scala 或 Groovy。”
 
 
Brian Goetz,
Java 语言架构师,
Oracle
 

JSR-292 — InvokeDynamic:使 JVM 更容易被其他语言访问

问:Java SE 7 中哪些特性令您尤为兴奋?

答:JSR-292,也就是所谓的“InvokeDynamic”JSR,让我倍感兴奋。JSR-292 的重点在于识别 JVM 架构中与 Java 语言联系过于紧密的方面,使之更为通用,从而消除 JVM 中许多非 Java 语言的难题,例如 JRuby、Jython、JavaScript、Scala 或 Groovy。JSR-292 提供了低级 VM 机器,编译器编写者可利用它与 VM 进行更加深入的交互,从而能与 VM 共享可用于制定优化决策的信息。这提供了解决非 Java 语言最常见性能问题的工具,例如动态方法调度或开放类的成本问题。JSR-292 还包括将在 Lambda 项目中使用的 VM 特性,支持比仅利用内部类时性能更高的闭包实现。

Java 并发性更新

问:2007 年,您还提到过,Java 开发人员应了解并发性虽然很难实现,但并非不可实现。您说:“人们往往从一个极端走向另一个极端,从认为‘这很简单 — 只要同步一切即可’转变为‘这太难了,不可能实现’。我对这两种观点都不赞同。就并发性而言,开发人员应该意识到他们必须谨慎、深思熟虑,还应请人审查他们的代码。”对此,您是否有所补充?

答:基本观点仍然是正确的,但现在的一些技术可以降低困难的范围和程度。不只是经过改进的库提供了常用语法的成熟版本,开发人员往往也能通过限制其程序中的共享可变状态来回避并发性的复杂性。如果没有共享状态,就不必协调对此类状态的访问,这样的协调往往会带来麻烦。函数式语言就是基于此原则构建的,但我们不必为获得这种好处而更换语言 — 只需要采纳不可变状态优于可变状态的理念,尽力增加不可变性、减少共享。在 Java SE 7 中,我们将添加一个分叉-合并分解框架,使您可以更轻松地编写自动跨多种硬件配置实现并行化的算法。

 
“Coin 项目的使命是识别可视作需要打磨的“粗糙边缘”的细微语言变化。这项工作邀请社区提供特性建议并提供规范和实现;在提交的近 50 项建议中,已有 6 项被采纳。”
 
 
Brian Goetz,
Java 语言架构师,Oracle
 
 
 
“我目前正在参与 Lambda 项目的工作,该项目为 Java 语言提供闭包(以及一组相关语言特性),同时升级核心 Java 库,以便更轻松地表示集合的并行计算。”
 
 
Brian Goetz,
Java 语言架构师,Oracle

Java SE 7 和 8 中的语言增强

问:您目前在 Oracle 的新角色是“Java 语言架构师”。能否为我们介绍一下这个新角色,以及 Java SE 7 和 8 中将提供哪些 Java 语言新特性?

答:在这个时候参与 Java 语言的开发确实令人兴奋。上一批语言增强是在 Java SE 5 中引入的,Java SE 7 和 8 都将提供新特性。在 Java SE 7 中,我们通过 OpenJDK 的“Coin 项目”开发了多种语言特性,这是一个真实的社区成功案例。“Coin 项目的使命是识别可视作需要打磨的“粗糙边缘”的细微语言变化。这项工作邀请社区提供特性建议并提供规范和实现;在提交的近 50 项建议中,已有 6 项被采纳。

部分建议非常简单,例如更灵活的整型数词汇规范,但也有其他一些建议创建了新的语言结构,使常见语法更细致、更不易出错,例如 try-with-resources 语句。

Java 8 确实提供了一些出色的内容,这个版本也并不像听起来那样遥不可及。我目前正在参与 Lambda 项目的工作,该项目为 Java 语言提供闭包(以及一组相关语言特性),同时升级核心 Java 库,以便更轻松地表示集合的并行计算。Lambda 提供的另一项重要特性就是虚拟扩展方法,这解决了一个由来已久的问题,即在定义了接口之后,您无法在不破坏现有实现的前提下添加新方法。

随着 Java 库的老化,这个问题越来越严重。其他语言已经通过特征 (trait) 或全面多重继承解决了这个问题,但我们不希望从根本上改变 Java 对象模型。扩展方法允许您为接口添加方法,新添加的方法指定对一个默认实现的引用,因此,如果实现该接口的类未提供该方法的实现,则将使用默认实现。这些接口方法是完全的虚拟方法,如果需要的话,那些实现可以提供优于默认的实现。我对该特性的形成方式非常满意,因为它提供了更大的灵活性,而且不同于大刀阔斧地更改对象模型,该特性不会使复杂度过度增加。

尽管扩展方法并非支持闭包的必要条件,但为语言添加闭包等特性也会给库造成压力,因为语言中存在闭包将使集合类型更加需要包含比如说像 forEach() 这样的方法。因此,Lambda 表达式成为最后一根稻草,迫使我们重新审视继承的灵活性。

但在此时添加闭包背后真正的推手是向多核发展的趋势。如果没有闭包,collections 类就无法轻而易举地提供内部迭代,for 循环将成为开发人员迭代集合的唯一途径。而 for 循环在本质上是串行的。因此,语言+库的现状迫使开发人员转而采用串行语法,将开发人员置于阿姆达尔定律的冲突困境下。

问:开发人员如何才能对此项目有所贡献?

答:我们的所有开发工作都是开放的。Lambda 项目Coin 项目均托管在 OpenJDK 上,邮件列表对公众开放。我们已从社区获得了大量反馈。

JVM 语言峰会

问:您协助主持了 2010 年 7 月 26-28 日举办的 JVM 语言峰会。您如何评价 JVM 的语言设计和实现现状以及 JVM 本身在当前和未来的功能?

答:JVM 语言峰会取得了极大的成功。在过去三年中,VM 开发人员(以及全部三个主要商业 VM 的架构师级代表)与语言设计人员和实现人员之间开展了成功的协作。大多数讨论结果都直接纳入了 JSR-292 过程。JVM 一直是实现语言的理想平台,但由于 JVM 有一小部分特定于 Java(尽管这个数量低于您想象的数量),所以难题始终存在。但通过与语言开发人员的协作,我们得以削减这些不匹配领域的范围和影响力。如果现在我要构建一种新语言,那我绝不会考虑编写一种原生编译器 — 而是更倾向于以 JVM 为目标,免费获得可移植性、垃圾回收、高质量编译、并发控制、工具、可服务性以及众多其他特性。

另请参阅

JSR-292
InvokeDynamic
Lambda 项目
Coin 项目
JVM 语言峰会

 

阅读本文的英文版本

前往 Java 中文社区论坛,发表您对本文的看法。