Open-Source Java on Linux

by Rick Moen
Last updated: 2002-12-22

The Java Model

I'm going to attempt a summary of the Java model, to the best of my understanding.

A Java programmer feeds his human-readable Java source through a compiler typified by Sun's proprietary "javac", or its open-source competitors. Any such compiler also needs an installed set of Java class libraries. Sun of course provide class libraries with their various Java pieces, but there are open-source projects to take their place, too.

The output of that compiler is (binary) object "p-code" (stored in a .class file, which is often compressed into a .jar PKZIP-compatible archive) for the virtual machine Sun intended all Java code to run on -- "Java bytecode". In Sun's model, the bytecode is fed to that virtual machine and executed in interpreted fashion. (That's the form in which proprietary Java code tends to get distributed, of course -- no user access to source code required.)

As far as I can tell, the bare virtual machine executable is called the JVM (traditional filename "java"). That plus class libraries, a source-to-bytecode compiler (traditional filename "javac") and sometimes other development tools constitute a JDK (Java Development Kit). That minus the compiler is a JRE (Java Runtime Environment, i.e., everything to run Java bytecode, but not to compile it). Usage as to what constitute JREs and JDKs is not consistent.

Anyhow, Sun produces the proprietary Java interpreter shipped packaged with Netscape Navigator/Communicator -- the one that either harfs Netscape all the time, or that Netscape harfs from above, take your pick.

Sun would prefer that all Java code end up compiled down to nothing lower than the Java virtual machine (compiled to bytecode), on grounds that compiling it further (to native machine code) "destroys portability, which is one of the main benefits of Java" (Java Programmers' FAQ, section 4, question 4). But quite a number of compilers have sprung up from third parties that compile bytecode-to-native-binary. Sun has no problem with "Just In Time" compilers (that compile machine code in memory immediately before executiion), and in fact produces a proprietary one named HotSpot.

In a nutshell: As demonstrated below, there are fairly complete Java 1.4-compatible open source stacks (avoid 1.5-specific features), such that one can code for that Java flavour comfortably. However, already-developed, third-party Java code, especially code that relies on proprietary Sun libraries or advanced graphical toolkits (e.g., Swing) or platform-specific libraries (such a com.* internals), will have problems.

Java Compilers (.java to .class):

Jikes:
http://www10.software.ibm.com/developerworks/opensource/jikes/?aw=50
Reportedly a very fast compiler, but a bit buggy.

guavac:
ftp://ftp.yggdrasil.com/pub/dist/devel/compilers/guavac
now unmaintained

BOCK (Bootstrap-Only Compiler Kit):
http://packages.debian.org/unstable/devel/bock.html
Tool by Charles Briscoe-Smith, intended primarily to compile the Jackal compiler for Java. Compiles Java source to navtive binary. Lacks error-checking; otherwise should be usable for any non-graphical Java code.

Jackal:
http://www.cs.vu.nl/~rveldema/jackal/jackal.html
Multithreaded Java-to-native-binary compiler toolkit for clusters of workstations.

Manta:
http://www.cs.vu.nl/manta/
Java-to-native-binary compiler.

gcj/gij:
http://www.gnu.org/software/gcc/java/
the GNU Compiler for Java. GPLed. Compiles in any of these three modes:

Limitation: Doesn't fully support JNI (2000-04): can't currently compile a .class file that uses JNI functions to implement its native methods. (I'm guessing the above JNI information is now obsolete.) Now includes Java runtime "gij" = GNU Interpreter for Java (which was based on GNU Classpath, and modeled after the standard Sun Java classes). The gij runtime module has filename libgcj, and "provides the core class libraries, a garbage collector, and a bytecode interpreter".

As of 2005-03: "gcjx can parse all 1.4 and most 1.5 language features. There are still some bugs in the 1.5 support, and generic methods remain basically unimplemented." (gcjx is a front-end for gcc).

2005-02: gcj now includes an implementation of the AWT native interface called libjawt. (Some support for Swing was present, earlier, starting 2004-01.)

KJC (Kopi Java Compiler):
http://www.dms.at/kopi/
The Kopi Project

Kiev compiler:
http://www.forestro.com/kiev/
Kiev is a variant, extended form of Java with type genericity and some prolog-like techniques to support rules-based programming.


Java Runtime Environments = JREs, and JVMs

Kaffe, by Transvirtual Technologies, Inc.:
GPLed JVM bytecode interpreter implementing "PersonalJava" (JDK 1.3) specs. http://www.kaffe.org/

Japhar:
http://web.archive.org/web/20040217034325/http://www.japhar.org/oji.html
JVM. Interpreter.
http://www.hungry.com/old-hungry/products/japhar/

SableVM:
http://www.sablevm.org/
Interpreter only. You need class libraries (SablePath).

KissMe:
http://kissme.sourceforge.net/
Interpreter only. You need class libraries (GNU Classpath).

gcj, GNU Compiler for Java:
http://gcc.gnu.org/java/
now include a Java runtime (which was based on GNU Classpath, and modeled after the standard Sun Java classes). The gcj runtime module has filename libgcj, and "provides the core class libraries, a garbage collector, and a bytecode interpreter". (As of 2005, libgcj and GNU Classpath are in the middle of merging.)

JanosVM:
http://www.cs.utah.edu/flux/janos/
U. of Utah's Flux Research Group
This JVM suppports multiple, separate, process-like entities (called "teams") within the virtual machine. Derived from the KaffeOS Java operating system, which in turn was based on Kaffe.

(Proprietary JVMs/JREs include Blackdown's, Sun's, and IBM's.)

LaTTe:
http://latte.snu.ac.kr/
BSD-licensed. Solaris-SPARC only, for now.
JVM and JIT compiler (bytecode-to-native).


Just In Time Compilers = JITs

Kaffe JITs:
Kaffe is said to have two JIT engines.

CACAO:
http://www.complang.tuwien.ac.at/java/cacao/
JIT compiler (bytecode-to-native).
DEC Alpha only. Binary-only for now, to be GPLed in the future.

tya:
http://sax.sax.de/~adlibit/
JIT compiler (bytecode-to-native). Claimed on http://www.debian.org/doc/manuals/debian-java-faq/ch3.html to be Java source to bytecode(?). Orphaned.

shuJIT:
http://www.shudo.net/jit/
JIT compiler (bytecode-to-native).

JVM-JIT compiler called ElectricalFire:
http://www.mozilla.org/projects/ef/
MPLed JIT compiler (bytecode-to-native).
You need class libraries (GNU Classpath or Sun JDK 1.2).

LaTTe:
http://latte.snu.ac.kr/
BSD-licensed. Solaris-SPARC only, for now.
JVM and JIT compiler (bytecode-to-native).

KissMe:
http://kissme.sourceforge.net/
JIT compiler (bytecode-to-native) under development.

Intel Open Runtime Platform:
http://orp.sourceforge.net/
BSD-licensed JIT compiler (bytecode-to-native). You need class libraries (GNU classpath).


Class Libraries

GNU Classpath:
http://www.gnu.org/software/classpath/ (As of 2005, libgcj and GNU Classpath are in the middle of merging.)

GNU Classpath Extensions:
http://www.gnu.org/software/classpathx/

SablePath:
http://sourceforge.net/project/showfiles.php?group_id=5523

Kore Class Libraries:
http://www.cs.utah.edu/flux/java/kore/
Now made obsolete by Kaffe's core classes.

Klasses.jar:
http://www.kaffe.org/
Complete classes set, furnished with Kaffe. Replced circa 2004(?) by GNU Classpath.

libgcj class libraries:
Merging as of 2005 with GNU Classpath.

Graphics Libraries/tools

Sun's standard (and very complex) proprietary graphics-handling toolkits are Swing and the earlier AWT (Abstract Window Toolkit) on which Swing was an elaboration. Both tend to be slow. See: http://developers.slashdot.org/comments.pl?sid=49057&threshold=0&commentsort=0&tid=117&mode=thread&pid=4963157#4964063

IBM's open-source Eclipse IDE includes a (partial?) implementation of SWT (http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/faq.html)
as a wrapper for native graphics objects, such as GTK+ or Motif on Unixes. Borland's proprietary JBuilder is also popular, but is said to tend towards unmaintainable code. Open-sourced Anjuta (for GTK+) is also very popular. Unfortunately, Eclipse and its SWT libraries' CPL licence terms preclude their lawful use with GPLed software. (It's hoped that IBM will eventually dual-licence the SWT components, following Mozilla's example.)

Further information on doing SWT (Standard Widget Toolkit) using gcj can be read here:
http://www-106.ibm.com/developerworks/java/library/j-nativegui/?loc=j


OJI Browser Plug-ins

Mozilla and derivatives now offer a standardised Open JVM Integration (OJI) interface for plug-in JREs.

Japhar:
The Japhar JRE now works with that interface:
http://web.archive.org/web/20040217034325/http://www.japhar.org/oji.html
http://www.hungry.com/old-hungry/products/japhar/

The Hungry Programmers' group in San Francisco, authors of Japhar, are still disorganised in the wake of the FBI and Secret Service's apparently mistaken early-morning seizure of all of their computing equipment in January 2004, as part of an (apparently) botched investigation of proprietary software bootlegging. It took them a very long time to get their gear and data back (some was never returned), and their losses in the interval included the japhar.org domain, now used for porn hosting.

Kaffe/OJI shim:
http://www.kaffe.org/ftp/pub/packages/kaffe-mozilla-oji/
Allows use of the Kaffe JVM as a Mozilla plug-in.

Fuji:
http://savannah.nongnu.org/projects/fuji/

Fuji is intended to eventually be an OJI for Mozilla, based on the GNU JRE, libgcj. At this date (2005-10-06), it's still in planning stages.

Sun's JRE/JVM/JDK stuff has always been proprietary -- and therefore so has Blackdown's (http://www.blackdown.org/java-linux.html), being a port of Sun's code to Linux. Sun's Java has been a moving target for open-source coders, such that most of their offerings lag Sun's in version support.

(This document makes only sporadic efforts to catalogue the many proprietary Java tools.)


Java Servlet Engines

GNU Paperclips (formerly GNUJSP):
http://www.gnu.org/software/paperclips/

Jserve:
http://java.apache.org/jserv/
Apache Software Foundation

Tomcat:
http://jakarta.apache.org/tomcat/
Apache Software Foundation

Geronimo:
http://geronimo.apache.org/
Apache Software Foundation

Jigsaw:
http://www.w3.org/Jigsaw/

Jetty:
http://mortbay.com/software/Jetty.html

JBoss Application Server:
http://www.jboss.org/products/jbossas
JBoss, Inc.

(To run servlets in Kaffe, you will probably need Paul Siegmann's substitute for Kaffe's servlet.jar class library:
http://www.euronet.nl/~pauls/java/servlet/)


Other Resources

Now, *I* don't really know diddly-squat about Java, personally. I just hunt down information on the Net, and squirrel it away for later investigation, mostly. But there are people who are genuine experts, and they've been busy writing:

jGuru Linux FAQ by Nathan Myers and others:
http://www.jguru.com/faq/home.jsp?topic=Linux&page=2

Java FAQ:
http://www.faqs.org/faqs/computer-lang/java/programmers/faq/

Debian Java FAQ:
http://www.debian.org/doc/manuals/debian-java-faq/

The Free-java mailing list:
http://www.lists.deus.net/mailman/listinfo/free-java

Free Java Resources page:
http://www.thefreecountry.com/programming/javatools.shtml

Escaping the Java Trap:
http://developer.classpath.org/support/
Developer Mark Wielaard's comprehensive 2005 explanation of the status of open source Java stacks.