GCJ

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