Sun 最近宣布了发布Java 6 版 OpenJDK 的计划,它将以 OpenJDK 7 的代码作为基础来创建向后兼容的 Java 6 的实现版本。InfoQ 通过与 Sun 的 Joseph Darcy 对话获得了关于此决定的更多信息。
当问到为什么 Sun 会决定在此时开源 JDK 6 时,Darcy 说这是为了让 OpenJDK 6 获得 OpenJDK 7 中的一些优势,以同时支持 Mercurial 源码库和二进制插件架构。同时,这也允许Sun 可以重用在OpenJDK 7 中已完成的代码审核和障碍清理工作——这是一个业已完成的显著成果,目的是避免重走整个过程去建立第二个代码库。当被问及OpenJDK 6 和已开源的 JDK 6 项目有哪些差别时,Darcy 指出现在的 JDK 6 代码是基于 Java 研究许可(Java Research License)开源的,而 Open JDK 6 将会基于通用公共授权第二版(GPL v2,即 GNU General Public License version 2 )许可方式开源。
InfoQ 接着问到创建 OpenJDK 6 对正在开发的 OpenJDK 7 会产生怎样的影响,Darcy 说:
在将 JDK 7 开源方面所投入的种种努力,已经把 JDK 7 的计划推到了前台,我们正在决定该选取哪些特性。无论如何,以已有的开源 JDK 7 来生成开源的 Java SE 6 的代价要相对小一些,所以我不认为会对 JDK 7 有任何实质性影响,兑现我们对 Java SE 6 的开源承诺会让 JDK 7 的发展得到更多关注:-)
在被问到基于 OpenJDK 7 开发 OpenJDK 6 可能存在怎样的风险时,Darcy 说在可能需要找出那些针对 Java 7 做过大规模结构调整的 API 并进行还原。不过他还是希望主要的工作是移掉新的类、方法和还原那些有过更改的规范,这些任务的风险相对较小一些。 Darcy 还提到,接下来的几个 Java 6 的更新版本将继续以现有 JDK 6 代码库为基础,现在还不知道 Sun 会不会以 OpenJDK 6 代码库为基础来发布更新。Darcy 还向 InfoQ 说明了开源 JDK 6 中的一些可选方案:
一种选择是在 OpenJDK 6 的升级工作空间内重做所有的代码审核和障碍清理工作。不过已没人愿意再去那样做了!另一种选择是通过开发一个技术性包装层来处理 JDK 7 组件,使其仅曝露基于 Java SE 6 的接口,在下面这篇文章中对该项技术进行了描述:由 Kenneth Russell 和 Tony Wyant 撰写的“在 Java SE 上模拟 Java ME 平台”。
基 本上来说,用户类需要在被载入 JVM 时进行重写,这样它们就只能从 Java SE 6 的角度来看世界;这项技术同样也可以处理反射操作。虽然它从技术角度来讲挺有趣的,但是仍然存在有很多需要加以改进的地方,而且有些还很复杂(如非 Java 接口等),所以这种技术会比我们选择简单的向后兼容分支方案要花更长的时间才能进入市场。
最后,InfoQ 向 Darcy 问到他对 OpenJDK 6 未来的期望时,他说:
短期来说,我的重点将放在为 OpenJDK 6 创建公开的 Mercurial 库上。这之后怎样进行代码库的开发还有待观察,部分原因是因为外部社区将会帮助测定结果。JDK 被应用在差异极大的各种条 件下,从大的银行集团,到独立开发人员,这让我们在解决发布模型中如何进行 Bug 修复和特性合并时,不得不针对这些跨领域的用户进行妥协处理。创建 OpenJDK 6 也让我们有机会重估 Java SE 6 的发布模型。也许现存的更新发布可以被转换成基于开源代码的;另一方面,也许保持不同的开源库和各自对应的更新会让我们更容易处理跨领域的需求。一旦 OpenJDK 6 发布并投入使用,我们就能得到更多的信息来指导将来发布模型的方向。
Darcy 还暗示 OpenJDK 6 可能在 JavaOne 2008 时到达一个主要的里程碑节点。
评论