JavaEnterprise JavaLinux and Java: The story goes on

Linux and Java: The story goes on content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

The early days

Back 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 directions

Before 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 Project

Thanks 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.

Kaffe has come a long way since Tim Wilkinson started the project in 1996. It now is a PersonalJava-1.1-compliant system, with a complete set of its own libraries. The (Swing-compatible) AWT is a pure lightweight implementation, not requiring any widget toolkits like Motif.

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).


GCJ 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.


Japhar is the LGPLed JVM from the Hungry Programmers. Given its straightforward design and platform integration (thread libraries), it is a good fit for embedded usage (e.g., as a Mozilla OJI plug-in), and probably has the smoothest learning curve. So far, it has an interpreter mode, with future plans for a JIT. Japhar can be used with the 1.1 class libraries of the Java-Linux Porting Project (but Classpath will certainly be the future library of choice — see below).


The ElectricalFire project is often erroneously described as a JIT; rather, it is actually aiming to become a complete JVM built around a high-performance JIT. ElectricalFire started out as a commercial Netscape project in 1997, died a sudden, political death at the beginning of 1998, and was resurrected as a true Open Source project under the NPL (Netscape Public License) in January 1999. So far, it consists of a rudimentary runtime and functional x86 JIT, running under Unix and Windows. (ElectricalFire is another potential Classpath user.)

The third group of projects we look into contains extensions for existing JVMs.

With the introduction of the JNI in Java 1.1, it became possible to write class libraries that are not tightly coupled to specific JVM implementations.


TYA is a plug-in JIT, developed by Albrecht Kleine for use in the Java-Linux Porting Project. Interestingly enough, it was built as a clean-room implementation, even though there still is no official JIT specification from Sun (other than an outdated 1.0-based article). TYA does not yet want to give way to the built-in 1.2 JIT from Sun and plans to adopt techniques like multi-pass compilation in order to speed up performance. It also is a potential candidate for a Japhar JIT.


Kazuyuki Shudo wrote shuJIT as a GPLed plug-in JIT for x86 versions of the Java-Linux Porting Project. Like TYA, it has to deal with missing JIT documentation from Sun. Rather than compete with the built-in 1.2 JIT, it exploits the capabilities of internal compilation in other interesting ways. One of these applications will be a soon-to-be-released, transparently distributed object system.

The following library projects are not tailored for a specific runtime environment and mainly (or completely) consist of Java code.


With the introduction of the JNI in Java 1.1, it became possible to write class libraries that are not tightly coupled to specific JVM implementations. The GNU Classpath project is the most prominent example of such a JVM-independent library. In fact, the only way to keep track of the exploding diversity of Sun APIs seems to be an Open Source development model, with contributions coming from around the world. The AWT (based on the GTK — the Gimp Toolkit) is still very new; but otherwise, Classpath is catching up fast, already featuring some 1.2 specific classes.


Given the variety of Java libraries and JVMs on Linux, the Mauve project is definitely of major importance. With all the different approaches and goals, it is crucial to have a common basis for compatibility tests. Mauve is going to fill this gap, building a comprehensive Open Source test suite. This is neither meant to be an obscure benchmark collection, nor is it aimed at redefining the standard, bypassing Sun’s distinguished role. However, if Java is to become a publicly available standard, the best way to encourage that growth (and avoid the possibility of negative ramifications) is to build a publicly available test suite.

Mauve can also serve as a fine example of how to conduct business in the Open Source community. Some of the projects mentioned above have their share of competition, but almost all of them contribute to Mauve in an effort to ensure compatibility.

The extraordinary success of some Open Source projects should not make us forget that many more have failed.

Finally, we turn to the bytecode compiler category. Since we’ve restricted ourselves to standard Java implementations, we aren’t looking at compilers for interesting Java supersets (like Pizza, GJ or Kiev).


Even if there was a GPLed predecessor called guavac, the first full replacement of Sun’s javac bytecode compiler seems to be Jikes, another interesting project of IBM’s alphaWorks. Since Jikes is fairly portable and comes with sources (even though under its own license), the fact that it was not written in Java is compensated for by increased speed and decreased invocation time. As a consequence, Jikes is a preferred choice for recompiling huge class libraries (like Kaffe or Classpath). In addition to a variety of Unixes (with Linux at the forefront), there is also a Windows version of Jikes.

Where do we end up?

The extraordinary success of some Open Source projects should not make us forget that many more have failed in terms of contribution and distribution. Which of the above projects are here to stay? With respect to the Java-Linux Porting Project, this mainly depends on Sun and the enthusiasm of its maintainers. As to the Open Source projects, this will depend on our will to let Java live up to its claims — a true vendor-independent standard.

About the author

Peter Mehlitz is co-founder of Transvirtual Technologies. He designed and implemented the AWT libraries of Kaffe. Prior to that, he worked as a technical lead for BISS GmbH, developing systems like the BSA C++-framework, the CThrough development environment, and the BISS-AWT Java libraries. Peter has about 20 years of experience in software development, using about a dozen different programming languages, with a strong focus on design issues and large, object-oriented frameworks (written in C++, Smalltalk, and Java). He holds an M.S. in aerospace engineering from the university of the German armed forces, Munich.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories