虚拟机接口比较

作者 R.J. Lorimer 译者 张龙 发布于 2008年8月11日

领域

语言 & 开发,

架构 & 设计,

运维 & 基础架构,

企业架构

主题

Java ,

开放源代码 ,

平台

标签

GNU ,

OpenJDK ,

开源Java

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

查看英文原文：Comparing Virtual Machine Interfaces

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

• 更早的 >