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 日正式公布，敬请关注。
