Andrew John Hughes 最近在其博客 首页上比较了OpenJDK 与GNU Classpath 两者的差异。Hughes 一直从事于OpenJDK 虚拟机接口的构建工作,该接口使得OpenJDK 通过这个接口与不同的VM 实现相结合。这项工作是 OpenJDK 创新的一部分,而 Hughes 则是这项创新的八个参与者之一。Hughes 今年年初的时候发布了相关的最终提议,而另外一些参与者的提议有:
- Java 集群——Neal Gafter
- 针对 Java2D 的 XRender Pipeline ——Clemens Eisserer
- JSR-310 日期 / 时间库——Stephen Colebourne、Michael Nascimento Santos
- 便携的 GUI 后端——Roman Kennke、Mario Torre
- 自由软件合成器替换——Karl Helgason
- Windows 下的 OpenJDK 构建过程——Ted Neward
在开发虚拟机接口的解决方案的同时,Andrew 还编写了文档来说明 OpenJDK 与 GNU Classpath 采用不同的方式。 JamVM 、 CACAO 、 Kaffe 等)。另一方面,OpenJDK 在过去几年中一直围绕同一个 JVM(Hotspot)进行构建。Hughes 那样,虚拟机和类库的边界是存在的,但是由于不断的发展,该界限已经变得不那么明显了:
这两个方案都提供了库和 VM 的分离。尽管 HotSpot 和 JDK 被置于同样的地方,但对于 OpenJDK 来说,这已经与最初的假设截然相反。 OpenJDK 协议上说,这使得不同版本 HotSpot 的替换成为可能。也就是说,由于 GNU Classpath 和任何的 VM 之间有众多不同的搭配,OpenJDK 中的 JDK 和 HotSpot 的联系可能会比 GNU Classpath 和任何的 VM 之间的联系显得更加紧密些。
Andrew 在比较过程中发现了这样一些差异:
- 预加载的本地库——libjava.so 是一个定制 Java 库,必须由 OpenJDK 预加载,这与通过类库加载刚好相反。Hughes 以 CACAO 为例,详细分析了 CACAO 是(一个开源的 JVM,已经支持 OpenJDK 了)如何处理这一切的:
CACAO 中, src/native/vm/nativevm.c 提供了处理一个特别的 OpenJDK 用例。这需要在 VM 初始化过程的早期进行处理,而且要在核心类尚未进行任何本地调用之前进行处理。
- VM 代理类——OpenJDK 中的很多核心类库直接由本地接口进行代理(Andrew 使用了一个本地声明的方法 Object.wait 作为例子)。与此相反,GNU Classpath 在大多数情况下会引入一个中间 VM 类,比如 Object.java 的中间 VM 类的则是 VMObject.java——这个类处理所有的本地代理,而且可以由其他 JVM 来替代。
- 由 VM 代码引发类库调用——在两个 VM 中都存在这样一种情况——从 VM 调用类库。因此,类库的内部结构对于 VM 的实现有着非常直接的影响。Hughes 提到了下面一些区别:JVM 启动、NIO 字节缓冲区的创建、线程和线程组的处理等。
我们可以根据不同不同的认证来获取 Sun JDK 的源码已经有很长一段时间了,但出于法律原因,GNU Classpath 并没有开放源码;而且 Sun JDK 的协议与开源并不兼容。但自从 Sun 将 JVM 和 JDK 的协议重新声明为 GPL 后,开发者就开始比较这两个平台了。OpenJDK 的创新结果将于 2008 年 8 月 18 日正式公布,敬请关注。
评论