I know that competition is natural (and quite often favorable) in open-source. But I can't help thinking I may be backing the wrong horse, and my time spent on it be in vain.
The different Free jvm's have different goals and constraints. I will describe my view of 3 jvm's I know.
GCJ is mainly a GCC extension, targeting static compilation of Java to native code and/or bytecode. It includes a minimal, but incomplete interpreter (gij). Its main native interface is CNI (Cygnus Native Interface) which is convenient for linking with C++ code, but which is non standard (incompatible with JNI) and is also incompatible with precise and moving garbage collectors. It's class library is mostly GNU Classpath with some differences (both projects "libgcj" and "Classpath" are under an on going merge). License is GPL with a linking exception (which makes the whole license very weak, intentionally).
Kaffe is the oldest of the Free jvm's. It has, currently, the best class library support (but implements quite old JDK versions; minimal support for latest libraries). Dalibor and others are currently working on making Kaffe to work with GNU Classpath class libraries. Kaffe has a JIT compiler and thus achieves very good performance, usually. Kaffe's primary native interface is gain a Kaffe-specific interface. JNI has been retrofitted to Kaffe; but Kaffe remains an unsuitable Free jvm to experiment with moving and precise garbage collectors. One of Kaffe's main "features" (or limitation, depending on you point of view), is that it is licensed under the GNU GPL, with NO exception whatsoever. This can have important consequences on an application that depends specifically on features of Kaffe.
[WARNING WARNING WARNING: I AM BIASED TOWARD SABLEVM]
SableVM is a newer project that was started from the ground up to build a robust, extremely portable, efficient, and fully specifications-compliant (JVM spec, JNI, Invocation interface, and soon to come: JVMDI, JVMPI(?), etc.) jvm that would be *EASY* to maintain and to extend. SableVM's core engine is an "interpreter: which uses state-of-the art techniques to deliver performance that can approach that of a "naive" just-in-time "JIT" compiler, while retaining the software engineering advantages of interpreters: portability, maintainability, simplicity. [Debugging a JIT can be a quite challenging problem in a multi-threaded environment]. SableVM's simplicity makes its source code very accessible, and easy to understand for new users/programmers.
SableVM's internal design was engineered to be as flexible as possible. SableVM is compatible with moving and non-moving collectors, provides "constant-time" interface method calls (in fact, there is no time difference between a virtual method call and an interface method call at runtime). SableVM's whole source code is currently < 60K lines, yet it provides properly guarded native JNI method transition, so that garbage collection does not have to wait for a runaway native thread to call back in the jvm to be able to do garbage collection. It has many other *robustness* design features, that have been the object of careful design. While SableVM does not currently implement all the different specifications, and has some incomplete parts (e.g. it lacks a bytecode verifier), it has all the structures in place so that the full specifications can be implemented without having to re-engineer the core design. This is not the sort of stuff that is easily visible to an end user, but on the longer term, it will allow SableVM to be an utterly ROBUST (and hopefully complete) jvm for executing Java bytecode. [We do have a SableJIT project, which is a "retargetable" JIT (easily portable to a new platform with minimal effort), that is already capable of compiling hot paths of methods, but it is NOT an optimizing JIT, nor can it fully compete with platform-specific JITs].
SableVM was designed from the ground up to work with GNU Classpath, and solely use the standard JNI interface as native interface (it has no other native interface). It is extremely portable (porting to Debian/hppa took only 25 minutes)! Usually, you can expect SableVM to be ~5 times slower than a high-performance, state-of-the art JIT (including Kaffe's JIT3). Yet, SableVM's interpreter is in average ~4-5 times faster than Kaffe's *interpreter* (which was not designed with performance in head; to be fair). The big difference is: simplicity (size and understandability of code) and portability (porting an optimizing JIT takes months), and robustness (debugging an interpreter is easy; debugging a JIT can be a nightmare).
Oh, yes! SableVM is licensed under the LGPL, so there are no worry to have about linking with applications, or even extending SableVM to provide specific features, and link proprietary, or GPL-incompatible applications to it. Please refer to recent thread of discussion on Debian-legal for a better understanding of the potential problems of a GPL'ed virtual machine[0]. The FSF's interpretation is even stricter than Debian-legal's[1].
There exist "hypothetical" plans to eventually combine some of these projects. Given SableVM license compatibility, one could very much imagine using SableVM as a replacement for gij to interpret dynamically loaded bytecodes faster within a gcj-compiled application. Also, one could see SableVM as providing a fast interpretation engine in a mixed mode interpretation and JIT compilation of hot methods Kaffe-based system.
[END OF BIASED SECTION :-)]
What you will find as common thread, in these 3 systems, is the following: All three systems aim to depend on a SINGLE class library: GNU Classpath. Most of the needs are in the class libraries, as the java language has gigantic class libraries. Currently, Classpath is >500K lines of code (yes, that's half a million). If you want to help, just help Classpath, and you'll be helping all Free jvm's that depend on it.
Of course, I would tell you to do so using SableVM, but I am biased. Dalibor made such a great point of remaining so very objective about the matter!
<BIASED-SECTION> Using SableVM, what nice is that if you have a bug, the interpreter is really easy to debug, yet, it delivers quite an acceptable performance during interpretation. Also, if you ever wanted to look at the internals of a jvm, SableVM provides a really neat internal structure. </BIASED-SECTION>
In any case, pick your preferred GNU-Classpath based Free jvm, and start helping. Everybody will be happy, even people of the other jvm projects.
Etienne SableVM project leader
[0] http://lists.debian.org/debian-legal/2003/debian-legal-200311/msg00012.html [1] http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
-- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
