January 17, 2021
Hot Topics:

Linux and Java: The story goes on

  • By Peter C. Mehlitz
  • Send Email »
  • More Articles »


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.

Page 2 of 2

This article was originally published on April 21, 1999

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date