GCJ is the component of the GNU Compiler Collection (GCC) which
compiles Java code. Unlike other Java compilers, it does not compile
to Java bytecode by default, but rather it compiles directly to
native machine code. This sidesteps the Java Virtual Machine (JVM) and
treats Java like any other compiled language. Being part of the GCC system, it can output machine code for any system GCC has a backend
for.
GCJ's method results in higher performance and faster start-up times, since the code does not need to either be interpreted at a performance loss by the JVM or recompiled as it is run (just-in-time compilation). It also changes the tendency of Java programs to seem in a world of their own, separate from all the other software on the system, by putting them on the same underpinnings as other languages such as C, C++, and Fortran. In effect, GCJ treats Java as 'just another language', not an Internet-based oddball as Sun's JDK does. Additionally, by not requiring an external program (the VM), it lessens the amount of infrastructure required to run Java programs.
GCJ originated at Cygnus in 1999, working with GCC version 2.95
but being outside the main GCC source tree. GCJ is separated into the
compiler, called simply gcj, and an implementation of the Java
standard library and runtime environment, libgcj. It also comes with a simple Java VM,
gij, that can be integrated with compiled Java code so that compiled
and interpreted Java code can be mixed in the same program. Another
option is to use GCJ to compile from the bytecode to native code,
although at a lower level of optimisation than that which can be used
with source files. It also supports the Compiled Native Interface
(CNI), which makes Java and C++ code binary compatible, with an added compatibility mode for JNI. GCJ was
integrated into the main GCC distribution with GCC 3.0. Additions to the Java language in version 1.5 have strained this original architecture, though, and for GCC 4.2 a new frontend based on IBM's Eclipse Java compiler will be merged.
Libgcj is making considerable progress implementing the Sun JDK class library, which is, after all, a moving target. The standard libraries are developed in conjunction with the GNU Classpath project, with the GCJ developers periodically merging the current Classpath source into their source tree. For several years, the most major omissions from Classpath were the AWT and Swing GUI toolkits. While the SWT toolkit developed for Eclipse was available, and the GNOME desktop provided native bindings, compatibility with the Sun JVM was desirable. At present, libgcj includes a near-complete implementation of AWT using GTK+ as a backend, and Classpath releases since the most recent GCJ release also include a Swing implementation.
GCJ is a very important project for the state of Free
Software. As it stands, most Java development is done with the
non-free Sun JDK and it and its equally non-free derivatives are
often the only VMs capable of running a given Java program. This has
caused Java programs to be second-class citizens on the Linux desktop,
and once prevented several distributions, particularly Debian and
Red Hat, from including Java programs in their main
distributions. Along with the kaffe VM and the GNU Classpath Java
library, GCJ serves to fix this problem. Debian now contains many
Java packages compiled with GCJ, and is seeking to convert as many
free Java packages as possible over to GCJ, kaffe, and Classpath.
GCJ is now a fairly mature piece of free software, and can be
found on many GNU/Linux systems. The current version of GCJ is
4.1.1, and its homepage is http://gcc.gnu.org/java/ .
Sources include the GCJ website at http://gcc.gnu.org/java/ , the GNU Classpath website at http://www.gnu.org/software/classpath/ , and the article "A look at GCJ 4.1" at http://lwn.net/Articles/171139/ .
(CC)
This writeup is copyright 2001,2004,2006 D.G. Roberge and is released under the Creative Commons Attribution-NonCommercial-ShareAlike licence. Details can be found at http://creativecommons.org/licenses/by-nc-sa/2.5/ .