Adam Messinger谈Java未来的整体规划
继近日发布的Java 7之后，InfoQ有幸采访到了Oracle Fusion中间件小组的开发副CEOAdam 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语言峰会上有不少有意思的讨论，你可以在这里查看结果。
查看英文原文：http://www.infoq.com/cn/news/2011/08/messinger-vava7-qanda
