Oracle为JDK 8寻求社区参与

据InfoQ报道，随着Java 7功能的日益完备，Oracle正在将注意力转向JDK 8，Java平台组的首席架构师Mark Reinhold正在寻求Java社区的参与：

我们已经知道JDK 8中会有一些大家伙，同时也会为其他大大小小的特性留下空间。因此需要时间来定义一个简单的流程，对JDK 8以及后续版本新特性的提案和计划进行收集、排序、审查和排列优先级。

这个流程应该“尽可能轻量化”，带上“简单的技术细节”，并且“对所有提交者开放，决策要透明”，Reinhold说到，现在能以文本文件的形式在Mercurial库里收集提案。

Reinhold提到的“大家伙”指的主要是那些已经被证明要包含在JDK 7里很困难，或者备受争议的东西。主要的内容可能是Java平台模块系统，还有lambdas（也被称作闭包或匿名方法）。

提供一个模块系统是Java 7的主要目标之一，但由于Sun选择开发一套自己的解决方案――Jigsaw，而不是用现成的OSGi，使得这项任务变得备受争议。Sun给出了两个原因。第一，他们希望让应用程序能绑定到更多的运行平台上，不止是OSGi的运行平台，这样用Java编写的桌面应用程序在Java支持的多种平台上就能更像一等公民了。第二，两个系统的依赖模型不同。Sun需要能将包拆分到不同的模块里，在运行时加载到同一个ClassLoader中――举例来说 java.util包可能会被拆分到不同的模块中（或者，对于内存受限的设备，甚至会有不同的实现）。为了支持这点，Jigsaw有一个本地依赖的概念，它是递归的。因此，如果模块“Swing”对模块“AWT”有一个本地依赖，模块“AWT”对模块“base”有一个本地依赖，那么在运行时模块 Swing、AWT和base最终都会在同一个ClassLoader里。OSGi有一个类似的概念，用的是片断（fragment）的形式，但灵活性稍差，因为它们无法自己表达依赖。当然，OSGi有可能为这些额外的需求增加支持，但无论采取哪种方式，Oracle都希望做到与OSGi兼容。 Java 8 JSR 中说到：

Java Platform Module对OSGi的采纳、互操作或者适应程度都将成为JSR专家的一个话题，Java SE 8专家组会讨论并得出结论的。

为语言增加Lambda表达式的计划有很多提议（BGGA Proposal | CICE Proposal | FCM Proposal | C3S Proposal），但还没有形成明确的结论，到底采用哪种方式。Project Lambda，以及同它一起的JSR 335，将重新审视这个问题。作为其中的一部分工作，会有一个提案来增加“SAM变换”（SAM conversion）支持，这可以在希望使用单一抽象方法接口或类的地方使用lambda表达式，可以正向兼容现有库。JSR还提议扩展Java语言接口的语义来支持虚扩展方法。在实现类没有提供扩展方法实现的情况下，这将允许接口指定一个静态默认方法来代表接口方法的实现。

说完了这些主要内容，JSR还提到了：

1. 源自Project Coin的很多小的增强。很有可能包含Josh Bloch的Collection Literals，旨在支持不可变的List、Set和Map内容，其中带有与数组初始化程序类似的语义。还有可能会看到针对JSR-292中的新JVM特性的源代码语法的复兴。
2. Type Annotations（JSR 308）：扩展的Java注解系统允许注解出现在类型的各种用法上。
3. 新的日期和时间API（JSR 310）。
4. Swing JDatePicker。

我们还希望Oracle继续构建Java对并行编程的支持，增加对filter、map和reduce这样的可并行化的批量数据操作的支持。

在EclipseCon上，Reinhold陈述了Oracle的首要目标是要保证Java仍然是第一语言和平台。