| 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）许可方式开源。 记者接着问到创建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还向记者说明了开源JDK 6中的一些可选方案：一种选择是在OpenJDK 6的升级工作空间内重做所有的代码审核和障碍清理工作。不过已没人愿意再去那样做了！另一种选择是通过开发一个技术性包装层来处理JDK 7组件，使其仅曝露基于Java SE 6的接口， 在下面这篇文章中对该项技术进行了描述： 由Kenneth Russell和Tony Wyant撰写的“在Java SE上模拟Java ME平台”。 基本上来说，用户类需要在被载入JVM时进行重写，这样它们就只能从Java SE 6的角度来看世界；这项技术同样也可以处理反射操作。虽然它从技术角度来讲挺有趣的，但是仍然存在有很多需要加以改进的地方，而且有些还很复杂（如非 Java接口等），所以这种技术会比我们选择简单的向后兼容分支方案要花更长的时间才能进入市场。 最后，记者向Darcy问到他对OpenJDK 6未来的期望时，他说：短期来说，我的重点将放在为OpenJDK 6创建公开的Mercurial库上。这之后怎样进行代码库的开发还有待观察，部分原因是因为外部社区将会帮助测定结果。JDK被应用在差异极大的各种条 件下，从大的银行集团，到独立开发人员，这让我们在解决发布模型中如何进行Bug修复和特性合并时，不得不针对这些跨领域的用户进行妥协处理。创建 OpenJDK 6也让我们有机会重估Java SE 6的发布模型。也许现存的更新发布可以被转换成基于开源代码的；另一方面，也许保持不同的开源库和各自对应的更新会让我们更容易处理跨领域的需求。一旦 OpenJDK 6发布并投入使用，我们就能得到更多的信息来指导将来发布模型的方向。 Darcy还暗示OpenJDK 6可能在JavaOne 2008时到达一个主要的里程碑节点。 |
