The early daysBack in 1995, things seemed pretty easy. Linux had just begun to grow beyond its original community, Open Source was not yet on the radar of the Fortune 500, and Java was still almost a research project.
Despite its commercial roots, Sun seemed to have a fairly liberal policy for distributing Java sources. That, in turn, attracted quite a few Linux advocates around Randy Chapman and Karl Asha. They did what all Linux hackers were supposed to do -- they created a port. The Java-Linux Porting Project was born, and it actually was one of the most usable Java environments of that time. It came with a downside, though. The porting team had to sign a Sun source license, and distribution was only allowed in binary format. The lack of a GPL (Gnu Public License)-like license clearly inhibited including the port in any major Linux distributions.
Linux and Java are probably the two most important factors in a software scene that has never been more competitive.
But there was relief. Bored by an assignment in Stockholm, Tim Wilkinson created his own version of a portable JVM (Java Virtual Machine), which pushed the limits beyond the interpreter and featured something that, later on, came to be known as a JIT (Just-in-Time) compiler. Because of its birthplace, it was called Kaffe, and it became the first clean-room JVM implementation. Since it had no class libraries of its own, the binary libraries from other ports, like the Java-Linux Porting Project, were used.
But who cared, except for the people who did this sort of thing for fun? Nobody expected this to become the next major "hot spot" of programming development.
And then it took off...Four years later, Linux and Java are probably the two most important factors in a software scene that has never been bigger or more competitive.
Due to its robustness, performance and availability, Linux is about to become a winner against heavily advertised commercial systems. Almost as a side-effect, it also assisted Open Source in becoming "en vogue," for which it still stands as the most successful example.
A closer look at the components of a Java implementation unveils a remarkable diversity that almost resembles a kind of "middleware operating system."
Boosted by the Web explosion, Java has become a mainstream programming environment faster than any of its predecessors. For the first time in history, the prospect of real platform-independent programming does not come with crippled functionality.
Given these two successful roots, does it mean that Java on Linux automatically had to become a success story? Not at all. Due to its proprietary nature, Java was never adopted by the Linux developer community to the same extent as Open Source programming environments such as Perl. It was not before the end of 1998 that Sun's Java division officially announced support for Linux (see Sun's 11/98 and 03/99 press releases).
But again, Linux has outpaced its competitors. Today, it is supported by more Java-related projects than most other operating systems. A number of highly motivated, talented programmers have once again shown how to put the Internet to work, if you are willing to share your ideas.
In all directionsBefore we look at particular projects, we have to cope with a misconception about Java that is still around after four years: Java is not just a Web-centric programming language. A closer look at the components of a Java implementation unveils a remarkable diversity that almost resembles a kind of "middleware operating system."
The pivotal part is still the JVM, featuring heap memory management (including garbage collection), threading, persistency (serialization), class management, a native call interface (JNI), and the execution engine (JIT and/or interpreter).
During the last two years, class libraries (or APIs) have been the most rapidly evolving part of Java. As a consequence, these libraries now even exceed the typical size of a JVM. The most expensive and difficult to implement library is still the AWT (Abstract Windowing Toolkit), which got even more difficult in the advent of "add ons" like the 2D and 3D APIs. Unlike Swing (a pure Java framework), many of these libraries come with an "upper" (Java) and a "lower" (native) half, glued together by the native call interface of the JVM (usually JNI).
The Java bytecode compiler is the third column of a Java implementation. Since it produces standard bytecode, it is not directly tied to a certain JVM, but it might be tightly coupled to a certain class library (like Sun's javac, which is part of the JDK).
Having said this, we are now ready to look at a collection of the most important projects. This is not a complete list of ongoing Java-implementation efforts, and we do not look at "root projects" such as Jolt, Kore, or BISS-AWT. Even without this, we end up with an impressive array of activities.
We start with full implementations, consisting of a JVM (or alternate runtime) and class libraries.
Java-Linux Porting ProjectThanks to Steve Byrne and other members of the Java-Linux Porting Project, the "official" Java implementation for Linux has been able to keep up with the pace of Sun's releases. There is even a pre-release of the huge 1.2 (or Java 2) version, featuring kernel threads, the built-in Sun JIT, and libraries like the 2D API. This achievement is even more impressive, given the fact that the Sun license is a very real barrier, and a binary-only distribution has to cope with the ongoing (g)libc, kernel and window-manager transitions of Linux.
Kaffe offers a huge set of configuration options and has been ported more than any other Java system.
Since the prevalent design goals were portability and scalability, Kaffe offers a huge set of configuration options (interpreter/JIT, threading systems, static/dynamic linkage, etc.) and has been ported to more platforms/architectures than any other Java system.
Because of its maturity (and availability of sources), academic and commercial research projects always have been a stronghold of Kaffe. The GPLed Desktop Edition, therefore, has an avid developer community, and TransVirtual continues to contribute extensively (besides working on a commercial version for embedded systems).
GCJGCJ is a Cygnus project that is a bold deviation from the Java mainstream. It is centered around four obvious facts: (a) Java applications have a considerable load-time overhead, (b) JIT compilers are not suitable for heavy optimizations, (c) the GNU GCC compiler (and its egcs descendant) already has been ported to most available architectures, and (d) many people are mainly interested in Java as a language, to be used on a single platform.
As a consequence, GCJ uses a strict AOT (Ahead of Time) approach, compiling Java bytecodes (or sources) by means of a special GCC front-end into optimized, native libraries, which are then executed in a special, shrink-wrapped runtime environment called libgcj. This sacrifices binary portability in favor of speed and load-time, which seems to be a reasonable trade-off for many applications (e.g., embedded systems). The libgcj is licensed under the terms of the LGPL (Library Gnu Public License).
Because AOT compilation of specific class sets is also an interesting approach for conventional JVMs, Kaffe provides a GCJ compatibility mode to directly execute GCJ-compiled Java libraries.
The next category includes JVMs without class libraries.