Adam Messinger 谈 Java 7 与 8

继近日发布的 Java 7 之后，InfoQ 有幸采访到了 Oracle Fusion 中间件小组的开发副主席 Adam Messinger 以了解此次发布及 Oracle 对未来 Java 8 计划的详细信息。

InfoQ：能否向读者介绍一下 Oracle 对于 Java 未来的整体规划？

Oracle 将会继续与其他小组合作来发展 Java，这包括一些大公司，如 IBM，也包括一些个人；通过一些组织进行协作，从 JCP（负责 API 及各种规范）到 Oracle 资助的各个开源小组，如 GlassFish 和 OpenJDK 以及其他一些参与者如 Eclipse。总体说来，就是 Java 平台将会继续发展，成为面向各个层次开发者的高效、高可靠、高性能的技术。 你只需查看 Oracle 发布的关于 Java 产品的开发范围就能了解到 Oracle 的承诺。Java SE 7 已经发布，同时 Java SE 8 也在进行当中。GlassFish 已经发布了 3.1 版，并且计划今年底发布新的版本；JavaFX 2.0 也快完成了、Java EE 7 也呼之欲出、NetBeans 7 也于近日发布，这都表明了我们现在的发展势头。当然了，Oracle Fusion Middleware 和 Oracle Exalogic Elastic Cloud 等产品都是基于 Java 的。

InfoQ：你认为 Java 7 中最有意思或是最重要的特性有哪些呢？

我认为大多数开发者都会觉得 Project Coin 中的语言变化是最有用的。这些变化（诸如 switch 语句中可以使用字符串、菱形操作符、多 catch 异常以及带有资源的 try 语法等）对开发者来说都是很有帮助的，因为所有这些特性的一个共同点就是他们都增强了现有源代码的可读性。这些变更的项目领导 Joe Darcy 还开发了一个注解处理器，这样开发者就可以扫描现有的代码以使用新的带有资源的 try 语法来替换掉老式，有时很容易导致错误的代码，而且新的语法更加紧凑。 我还要强调一下新的 Filesystem API， 它公开了现代文件系统的一些关键特性，如文件变化通知与符号链接，还支持更快速的块操作，比如搜索目录树等。我认为这些特性是最为重要的。

我认为最有意思的特性当属新的 Fork/Join API，它有助于开发者们编写出能够并行运行的应用。过去，只有针对高端服务器编写数据或算法密集型应用的开发者们才会在意应用是否是并行运行的，因此也会更加充分利用多核 / 多处理器架构的所有能力，但现在我们看到带有四核芯片的台式机也都是普通之物了，双核的笔记本和智能手机也成为了标配。用不了多久，更多的开发者们将会考虑并行程序设计了。

InfoQ：NIO 2 向 Java 引入了真正的异步 I/O API。为何说这是很重要的呢？它的使用场景有哪些？

异步 I/O 是编写高可伸缩的 I/O 密集型应用的一把利器。它与非阻塞 I/O 有几分相似，后者属于最初的 NIO 的一部分，在 Java SE 1.4 中被引入进来。非阻塞 I/O 非常适合于处理大量的开放网络连接，但却不适合于随机访问的 I/O 设备，如磁盘驱动等。异步 I/O 既适合于连续设备，也能胜任随机访问设备，它非常适合于某些应用架构。与非阻塞 I/O 一样，我认为很多开发者并不会直接使用异步 I/O API，但一旦使用就会发现它的价值所在。

InfoQ：NIO 2 中新的 Filesystem API 似乎违背了 Java 一次编写，到处运行的原则，因为 Java 开发者可以通过它访问文件系统的文件特性。这是个好想法么？如果是，那为何不将其拓展到其他领域，比如可以从 Java 中执行通用的系统调用呢？

我不确定这么做是否违背了 WORA 原则，但即便如此，这也肯定不是第一次。Java 在隔离开发者与底层架构和平台的细节上做的很棒，但它无法掩盖这样一个事实：平台与平台之间是不同的。一个显而易见的例子就是并非所有计算机都有显示器，这样他们就没法以任何合理的方式运行 Swing 代码了。是的，Filesystem API 可以访问到诸如符号链接等特性，并非所有平台都有这个特性，但如果你非要抬杠，那我会说并非 Java 所运行的所有平台都具备文件系统！ 我们相信 WORA 原则是可靠的，这也正是 Java 变得如此成功的主要原因，我们将会继续恪守这个原则。然而，我们也相信 Java 必须要能与特定于平台、设备及实现的特性相结合才能继续成长和成功。现在已经有了经过验证的方式可以实现这种融合，比如通过一些抽象 API 再搭配上定义了特定于实现扩展的供应者。这正是 Filesystem API 和其他众多的 Java API 所使用的架构，无论这些 API 是标准的抑或是第三方的都是如此。

至于最后一个问题，我觉得在 Java 中能够更加轻松地进行系统调用是件很有意义的事情。我希望 Java 社区（如 OpenJDK、JCP 等）能够就这个问题展开讨论。

InfoQ：很多人认为需要向 Java 中添加 lambdas 支持的一个主要原因在于 Fork/Join 的需要。但你们为何首先发布了 Fork/Join？这不是表明在将 lambdas 添加进来前这个 API 都是有问题的么？

这纯粹是扯！我们通过多种发布途径帮助开发者编写并行应用。这起始于 JDK 1.5，那时 Doug Lea 和他的 JSR 166 专家组添加了 API 层次支持以将应用分解为多个可以并行执行的任务。JDK 7 中的 Fork/Join 框架是实现这个目标的另一种手段，但仍然提供了一套工具，当开发者了解该如何分解其编程任务时，他们就可以使用这些工具了。 我们要做的是尽可能将更多的设计与实现工作自动化以使应用能够并行运行。Project Lambda 包含了 lambda 表达式，用于实现更加简洁的封装函数行为以及并行算法的平台实现，如过滤和映射等。他们可以通过现有的并行 API 实现，如 Fork/Join，但这只不过是实现的细节问题而已。Lambda 有助于我们将并行程序设计带给大众，但我敢肯定总会有一些“强力”开发者使用 Fork/Join 提供的一些更加手工的技术。

InfoQ：有人提议说 Java 8 可能会定义自动的并行块数据操作，如过滤、映射和降级。能否谈谈呢？

这些块数据操作非常重要，因为他们可以通过内部遍历实现自动化的并行操作。这意味着现在不必再编写传统的循环来过滤集合（这是外部遍历），你只需在 lambda 表达式中定义过滤器，然后将其传递给集合的 filter 方法即可，后者会在内部进行遍历操作。因为 filter 方法可以控制遍历实现的方式，因此在可能的情况下它会将工作分离到多个处理器核心上执行，但这一切对于开发者来说都是透明的。

InfoQ：Java 7 通过 invokeDynamic 首次向 JVM 引入了新的字节码指令。Project Coin 中有一个相当不错的提案，建议在 Java 语法中增加 invokeDynamic，但却被放弃了。能否介绍一下放弃它的背后原因么？它会在 Java 8 中重出江湖么？

在经过缜密透彻的分析后，我们认为通过一个只会被少数人所用的特性来扩展 Java 编程语言并没有什么意义。我也怀疑 Java 8 会重新考虑它。

InfoQ：关于对 JVM 上其他语言的支持，你认为有哪些语言会从进一步的 VM 级的改变中获益？

我们并没有为了这种支持而选择语言。我们所采取的方式是仔细观察除了 Java 以外，开发者还对哪些语言感兴趣。对 VM 进行额外的增强以改进 JRuby、JavaScript、Scala 及 Clojure 的性能是很有价值的，但他们只不过是大家能够看到的而已。

InfoQ：你认为接下来还会对语言支持进行哪些调整——continuations、tail-calls 还是 interface injection？Java 8 会支持他们么？

现在说这些为时尚早。目前 John Rose 正与很多语言设计者和实现者通力合作，他们采取了很务实的方法来对这些特性建立原型，然后评估哪些特性会带来最大的价值。事实上，在上周举办的 JVM 语言峰会上有不少有意思的讨论，你可以在这里查看结果。

查看英文原文： Adam Messinger Talks to InfoQ About Java 7 and 8