Assemble your java from free standard pieces
Just saw A Lazy Developer Approach: Building a JVM with Third Party Software by Nicolas Geoffray, Gael Thomas, Charles Clement and Bertil Folliot. They show something I always found super cool about the community around GNU Classpath and the free software community in general. Working together on parts of free software to enable everybody to stand on top of the shoulders of giants.
The development of a complete Java Virtual Machine (JVM) implementation is a tedious process which involves knowledge in different areas: garbage collection, just in time compilation, interpretation, file parsing, data structures, etc. The result is that developing its own virtual machine requires a considerable amount of man/year. In this paper we show that one can implement a JVM with third party software and with performance comparable to industrial and top open-source JVMs. Our proof-of-concept implementation uses existing versions of a garbage collector, a just in time compiler, and the base library, and is robust enough to execute complex Java applications such as the OSGi Felix implementation and the Tomcat servlet container.
They have some nice things to say about GNU Classpath and our VM Interface
Industrial JVMs often have their own implementation of garbage collection, compilation, interpretation and class libraries. Open-source JVMs tend to all use the GNU Classpath base library implementation [6] (some JVMs are currently being ported to the newly open-sourced Sun implementation), and the Boehm garbage collector [22]. GNU Classpath and Boehm GC are popular among JVM implementations because they are virtual machine agnostic, hence they do not depend on a particular JVM implementation.
[…]
We started the project with GNU Classpath version 0.93. LadyVM now uses the latest version, 0.97.2. Since GNU Classpath has had many releases before 0.93, the API changes between 0.93 and 0.97.2 were minimal.
GNU Classpath moved to java version 1.5, including generics, with release 0.95. Since the JVM specification did not change between version 1.4 and 1.5, the move to GNU Classpath 0.95 did not require any changes in LadyVM. The only modification we made was due to the ldc opcode, which loads classes since JVM 1.5.
So next time you want java somewhere, just pick up the free software pieces already there and click them together for your environment :)
Not quite there yet – they could have saved the 18kLOC c++ code iff twisti would turn the vmgen vm backend into a library that can plug into LLVM, libjit, etc. ;)
But good to see someone follow Kaffe on its road to become one small configure script, and show awesome results for it.
Interesting to read that Gary B. considered this library when implementing shark but found it unsuitable.
http://gbenson.net/?p=82
Choice is always good but as Dalibor suggests, so is re-use. Be nice to see Gary’s zero work support pluggable JITs using twisti’s backend :)