A look at GCJ 4.1

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 OpenOffice, Eclipse 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 projects. 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 be found here.

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 provide xml.validation. 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 Mauve 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. He 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 feature.

Various GCJ hackers will meet in two weeks at the GNU 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.