GCJ: Quo Vadis?

Andi Vajda asked whether GCJ would cease to exist if Sun were to release the source code for Java and its tools under a really Free licence. I have also seen such questions asked on Slashdot, OSNews and other fora.

The response from Andrew Haley mirrors what I personally think of the situation - as long as there are hackers willing to maintain it, GCJ would continue to exist. Miguel de Icaza says that among the two types of hackers who usually work on Free Software in their spare time, GCJ and GNU Classpath only attract the Free Software idealogues and not those who want to get something free (gratis) working for them since Sun's JDK already works well for them and is free. Tom Tromey has a more philosophic take on the current situation - almost ascetic in fact. All this is enough to make a GCJ or GNU Classpath hacker reflect on the current state of Free Java, the utility of his contribution to it and the impact of a fairly Free release of Java source code from Sun. Despite being an extremely erratic contributor working on the fringes of Free Java, I cannot help doing the same.

It was about four years ago that I first flirted with GCJ. I wondered, for no particular reason as is usually the case with me, if it was possible to use GCJ to create native GUI applications with SWT in Java on Windows. I found out that the support was almost there and with a little effort and a lot of support from the GCJ hackers (especially Tom), I was able to add in that support and contribute it back to GCJ where it was accepted with minor modifications. That was my epiphany with Free Software. Until then I was more impressed by the fact that I could get so much decent-quality software for free than the liberty to make modifications to such software. But now I began to realise that having the source code available to you meant that you could change it yourself to fix its shortcomings and share your improvements with the other users. It also meant that the availability of the software did not depend on the solvency of the vendor or its willingness to maintain it. There were many other factors in favour of Free Software that became apparent to me over time. Suffice it to say that I finally understood what that twitchy, smelly and passionate preacher of Free Software was talking about all the time.

In time, my original itch died out (like so many of my digressions in life) but I continued to work on GCJ. I quickly moved from Windows to Linux (since that was the only platform that I enjoyed working on) and began fixing front-end bugs more out of a desire to help folks than to fix anything that was affecting any of my personal or professional work. This played a part in the fact that my track record with GCJ has been absolutely abyssmal (except perhaps in the area of contributing the most noise to the GCJ mailing lists). My pathetic time-management skills and a propensity to be carried away by even the slightest distraction have also played a big role. Since I worked on GCJ in my free time at home and I did not want to compromise too much on my personal life (spending time with my family, watching movies, reading books, meeting friends, getting enough sleep, etc.), I rarely found the time to debug and test anything except the most trivial of bugs. Finally, my tendency to "wait and watch" (first for GCJX and now for ECJ) has not helped matters much either.

There are some inherent problems with GCC and GCJ too. The GCJ front-end seems to have been written in a hurry in order to get as many things working as fast as possible with not much thought given to overall maintainability. The people who originally wrote it have moved on to other things in life leaving others with little idea of how it all works. Subsequent hackers (including me) have always made incremental changes to fix immediate issues rather than perform any big refactoring of the code, with the natural result that the code has become even more unwieldy now than before. To fully bootstrap GCC, especially with checking enabled, and then to run its testsuite takes an awful amount of time, especially on slightly older hardware (like my otherwise perfectly capable P3-based system). This is a huge barrier for most prospective hackers. (I reserve my rant about the disastrous effects of bundling several language front-ends and their ever-bloating runtime libraries into a single compiler system for another day.) Until recently, the ubiquitous tree data structure was used in funky ways for almost everything in GCC. There is precious little documentation for a programme of this complexity and some parts of this documentation is out-of-date. The best way to understand stuff in GCC is to read through the source code, to watch the operation of the relevant parts in a debugger and to ask questions on the mailing lists when you do not understand something even after doing all this.

All these are problems that can be overcome one way or the other. The biggest problem with GCJ however is the sheer paucity of hackers willing to work on it to improve it compared to the number of people willing to use it and reporting problems with it. This situation is particularly severe for Windows. Were it not for Red Hat's sponsorship of some critical GCJ hackers (and the heroic efforts of Tom in particular), GCJ would have been in a very bad shape by now. This situation really makes me realise how true Miguel's observations are with respect to hackers of Free Software and Free Java.

A Free Java from Sun would not obviate the need for GCJ though. I personally feel that ahead-of-time compilation to native code providing more opportunities for aggressive optimisations (platform-agnostic as well as platform-specific) and a more straightforward integration with C/C++ via CNI are enough to show the utility of GCJ orthogonal to the status of the freedom provided by Sun's JDK.

This post has already become the longest I have ever posted, so I will reserve my rant about how Java the language and its bloated "standard" runtime is not even worth spending so much time and effort on in the first place, for another day.

Tweet