Open-Source Java on Linuxby Rick Moen
[RM note as of 2008-08-19: A significant portion of this
page is now effectively obsolete or less important, because of
Sun Microsystems putting 95-96% of OpenJDK (all the pieces it owned)
under GPLv2, over a one-year period between May 2006 and May 2007.
Red Hat, Inc. then assisted that effort by recoding the remaining
4-5% encumbered code using work based on GNU Classpath, this
backfilling project being referred to as the "IcedTea Project",
which met essentially all requirements to become a free-software
OpenJDK starting IcedTea6 version 1.2.
In June 2008, the resulting improved OpenJDK, with code from
IcedTea6 / GNU Classpath, was finally able to
pass Sun's Java Test Compatibility Kit (TCK) as a fully compliant
and fully open source / free software "Java 6" (J2EE v. 1.6)
implementation. That codebase shipped in
Fedora 9, and should now gradually propagate to other Linux
distributions as their software gets refreshed. (E.g., package
openjdk-6 entered Debian-unstable on 2008-07-12, ebuild "icedtea6"
entered Gentoo around 2008-06
2), package "icedtea" v. 1.2 became the default JVM on ArkLinux around 2008-06-25,
Ubuntu 7.04 "Hardy Heron's" Universe collection accepted package
"openjdk-6-jre" around 2008-06.) See:
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-to-native-binary compiler, unmaintained since 2001. Author disclaims: "This is a first release, not yet complete (especially the javalibs are incomplete). It is a research vehicle, not a production quality compiler, and, as such, it is probably not very stable."
the GNU Compiler for Java. GPLed. Compiles in any of these three modes:
- Java source code directly to native machine code (needs GNU
- Java source code to Java bytecode (class files),
- and Java bytecode to native machine code.
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):
The Kopi Project -- discontinued in 2005.
Kiev is a variant, extended form of Java with type genericity and some prolog-like techniques to support rules-based programming. Discontinued in 2006.
Java Runtime Environments = JREs, and JVMs
Kaffe, by Transvirtual Technologies, Inc.:
GPLed JVM bytecode interpreter implementing "PersonalJava" (JDK 1.3) specs.
JVM. Interpreter. Very, very obsolete and unmaintained.
Interpreter only. You need class libraries (GNU Classpath). Unmaintained and deprecated: Author suggests using other open-source JVMs, instead.
gcj, GNU Compiler for 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.)
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. Project appears to have reached its 1.0 release in 2003, and then stopped.
(Proprietary JVMs/JREs include now-defunct Blackdown's, Sun's, and IBM's.) [2008 addendum: Full open-source Java kits based on Sun's 2006-7 open-sourcing of 94-95% of Java, followed by Red Hat's backfilling of the rest, are en-route to upcoming Linux distribution releases starting with Fedora 9, such t hat proprietary JVMs/JREs will soon be a non-issue.]
BSD-licensed. Solaris-SPARC only, for now.
JVM and JIT compiler (bytecode-to-native), implementing Java 1.3. Development site seems to have been unreachable since October 2007.
Just In Time Compilers = JITs
Kaffe is said to have two JIT engines.
JIT compiler (bytecode-to-native).
Initially binary-only for DEC Alpha; rereleased under GNU GPL in 2004.
JIT compiler (bytecode-to-native). Orphaned at the (still-findable) circa-2001 v. 1.8 release.
JIT compiler (bytecode-to-native). As of August 2008, its most recent release was in August 2005.
JVM-JIT compiler called ElectricalFire:
MPLed JIT compiler (bytecode-to-native).
You need class libraries (GNU Classpath or Sun JDK 1.2). Project was orphaned starting 2006.
BSD-licensed. Solaris-SPARC only, for now.
JVM and JIT compiler (bytecode-to-native). Developer site seems to have been unreachable since October 2007.
JIT compiler (bytecode-to-native) was (circa 2001) under development, but may or may not have even seen the light of day. Unmaintained and deprecated: Author suggests using other open-source JITs, instead.
BSD-licensed JIT compiler (bytecode-to-native). You need class libraries (GNU Classpath). Project seems to have been inactive since 2002.
GNU Classpath Extensions:
Kore Class Libraries:
Now made obsolete by Kaffe's core classes.
Complete classes set, furnished with Kaffe. Replaced circa 2004(?) by GNU Classpath.
libgcj class libraries:
Merging as of 2005 with GNU Classpath.
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 () 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-license the SWT components, following Mozilla's example.)
Further information on doing SWT (Standard Widget Toolkit) using gcj can
be read here:
OJI Browser Plug-ins
Mozilla and derivatives now offer a standardised Open JVM Integration (OJI) interface for plug-in JREs.
The Japhar JRE now works with that interface:
The Hungry Programmers' group in San Francisco, authors of Japhar, became for a long time 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.
Allows use of the Kaffe JVM as a Mozilla plug-in. Last maintained 2002.
Fuji was intended to eventually be an OJI for Mozilla, based on the GNU JRE, libgcj. The project was apparently discontinued in 2006.
(This document makes only sporadic efforts to catalogue the many proprietary Java tools.)
GNU Paperclips (formerly GNUJSP):
Apache Software Foundation. Unmaintained since 2000.
Apache Software Foundation
JBoss Application Server:
(To run servlets in Kaffe, you will probably need Paul Siegmann's
substitute for Kaffe's servlet.jar class library:
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:
java.net Linux Community:
Developer information site. Mostly open source, but not entirely.
Free Java Resources page:
Escaping the Java Trap:
Developer Mark Wielaard's comprehensive 2005 explanation of the status of open source Java stacks. Covers some important software pieces that have not yet (as of 2008) been incorporated into this page, and omits minor and discontinued projects that are included here.
Viva Open Source Java - Operation Java Freedom:
News/documentation-tracking site about open-source Java.