Oracle 为 JDK 8 寻求社区参与

  • Charles Humble
  • 丁雪丰

2011 年 4 月 10 日

话题:Java编程语言语言 & 开发架构

随着 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 仍然是第一语言和平台。

Oracle 有 20,000 名 Java 开发者,除了核心数据库以外的一切都是用 Java 编写的。如果 Java 没落了……那将会有一笔巨大的重复投资。

Java 8 有望在 2012 年末发布。

阅读英文原文:Oracle Seeking Community Input for JDK 8

Java编程语言语言 & 开发架构