One of the components of the GNU
Compiler Collection (GCC) is GCJ,
the GNU Compiler for the Java programming language. GCJ is a compiler
that can generate both native code and bytecode from Java source
files. GCJ includes a runtime library (libgcj) that provides all runtime
support, the core class libraries, a garbage collector, and a
bytecode interpreter. Programs created by gcj can dynamically load
and interpret class files or native shared libraries resulting in
pure, or mixed native/interpreted applications.
Version 4.0 of GCJ introduced a new
deployment model that made is much easier for distributors to
package traditional Java programs as native applications without
requiring any source level changes. For version 4.1 of GCJ, this new
binary compatibility (BC) ABI has also been used for parts of the
core library, but only for a minimal subset which includes
XML, CORBA and imageio.
This change means that those parts of the core library can easily
be upgraded with newer versions by the end user.
In time, it will become possible to upgrade more parts of the
core libraries in a similar manner.
All of the major GNU/Linux distributions use GCJ to support programs like
and Tomcat. So it is not surprising
that the improvements
in GCJ 4.1 have been very application and distribution driven. All of
the applications supported by GCJ 4.0 run with more stability
under GCJ 4.1.
And support has been added for a large range of programs like the Azureus
bittorrent client, the RSSOwl
feed reader, the JOnAS
application server, and the java-gnome based system monitoring and
debugging tool Frysk.
The core library from GCJ 4.0 was based on GNU
Classpath 0.15, which was released almost a year ago. The core
library of GCJ 4.1 has been updated to use GNU Classpath 0.19, plus
selected bug fixes from the new 0.20 release. GNU Classpath is a
shared development effort that is supported by a wide variety of
These projects include interpreters like JamVM and
SableVM, just in time compilers
like Kaffe and Cacao,
operating systems like JNode and
IKVM, and .NET/Mono interoperability and
"java-in-java" implementations like JikesRVM.
With around 20
projects being based on GNU Classpath and more than 40
people from all these different groups working very hard this
last year, the coverage and completeness of the core libraries have
increased enormously. An overview of all the supported packages can
Besides lots of correctness and completeness fixes in the more
basic packages (lang, math, io, net, text and util), GCJ 4.1 will
support HTTP operations on data larger than available memory. It will
better support the new NIO package, including correct file locking.
Support for AWT, the abstract window toolkit, has been much improved
through better integration with GTK+, allowing the transparent copy/paste
of various data types between applications. Image loading should be
faster and more robust. And the GNU JAWT implementation makes it
possible to interface AWT Canvas painting with native screen
resources (allowing the jogl
OpenGL bindings to work).
XML support has been expanded to include
xml.transform and xml.xpath. Free Swing has seen a lot of updates
that should make it possible to run simple GUI applications using
various look-and-feels, and includes support for JTrees and JTables.
RMI and Corba implementations have been added, including support for
RMI over IIOP.
There is even a sample distributed five-in-a-row game included that
has been implemented using Free Swing and Corba.
Looking toward GCJ 4.2
GCC 4.1 has been in freeze since November, to make sure all
regressions are fixed. This means that no major features have been added
since then. GCJ now supports dropping a classpath directory inside
the GCC source tree to get updated core library support.
Because of the intertwined nature of the Java language, runtime
and libraries, this isn't completely trivial for end users yet.
The core GCJ developers will have a much easier way to get a more
up-to-date core library. End-users will have to wait until version
4.2 for easier core library upgrading,
through more extensive BC ABI support.
A lot of projects for GCJ 4.2 have already started. There is a lot of
interest in making static linking work more smoothly, especially
for embedded devices and for windows developers. There are different
projects for shrinking the size of executables, by stripping
reflection data, or the core library (micro-libgcj).
There is also work on getting more precise information to the
garbage collector in order to decrease overall memory usage. To better
support debugging of interpreted classes, (for native compiled classes
you can just use GDB) support for JDWP is being added to the libgcj
interpreter. This should also enable debugging applications from
inside of IDEs like Eclipse.
The GNU Classpath core libraries are also being updated to support
even more core packages. Work is being done on integration of a full
JCE crypto provider (GNU
Crypto and Jessie) to
provide transparent https, ssl and tls networking support. The
regular expression engine, gnu.regex, is being updated from the old
Posix syntax to provide compatibility with the util.regex syntax and
features. StAX support has been added, and work is being done to
The beans package has been extended to support XMLEncoder serialization.
Printing support through CUPS is
being added. An ALSA provider that handles MIDI In ports and a DSSI
provider that handles software synthesizers has been added. Lots of
new security related tests have been added to the
project to check the permission-based access controls in the core
library. And GNU Classpath has added support for the new Java 1.5
language features like generics, although those are still being
developed in a separate branch.
Beyond GCJ and GNU Classpath
The GPLv3 draft has been
enthusiastically received by the GCJ and GNU Classpath hackers. The
Java programming language has traditionally been used for
extensions to other projects such as Apache and Eclipse.
Software from those projects have been licensed under GPLv2-incompatible
licenses, preventing cooperation and code sharing.
The proposed License Compatibility clause in GPLv3 will make
code sharing between GCJ/GNU Classpath and Apache/Eclipse possible.
Tom Tromey is the main developer of GCJX, the GCJ frontend
successor that supports the new 1.5 language features.
surprised everybody soon after the GPLv3 draft was released
by proposing to look into replacing the Java source-to-bytecode part
of the GCJ compiler with the Eclipse compiler (ECJ) instead of using
his own GCJX effort. The GPLv3 isn't final yet (and won't be for a
year), and there are lots of technical issues to discuss. But sharing
code and resources between projects seems like a very attractive
Various GCJ hackers will meet in two weeks at the
Classpath and Friends meeting during FOSDEM. It will be very
interesting to see how the roadmap
of these projects looks at the conclusion of that event.
to post comments)