GNU/Andrew’s Blog

It seems a lot of projects and distributions are seeing new releases either now or in the very near future. This week, we had a very quiet minor release of GJDoc, the GNU Classpath equivalent to javadoc. 0.7.9 includes a few changes that were previously only available in CVS, but the main one is a small fix that allows Classpath 0.97.1 documentation to be built. Our minor .1 release for 0.97 fixed a bug where the JSR166 code was not being included in the documentation build. With this fixed, it turns out gjdoc would no longer build the documentation as java.util.concurrent.TimeUnit is a rather complicated enumeration that our hacks can’t bypass. Michael Koch, in packaging GJDoc for Debian, was kind enough to point out that having the current release of GJDoc not being able to build documentation for the current release of Classpath was a bad thing. A quick release fixed this by pushing out the fix I made for this issue back in March. Of course, you can now use javadoc for IcedTea/OpenJDK to build the documentation instead; with another Free JDK about, there’s no need to just rely on GJDoc.

I do wonder what the long term future for GJDoc should be. It only works with GNU Classpath at present through a nasty bunch of hacks which cause the parser to skip chunks of the input. It really needs a major cleanup and to be made to work properly with 1.5 code. Thomas Fitzsimmons suggested we should merge it into the GNU Classpath codebase which seems a good idea, as it means we don’t run into this same revision hole we just did. However, it is worth maintaining GJDoc at all? For me, the main features it has over the OpenJDK javadoc are in speed and the look of the output. A key feature is also that it it plays nicer with Free Software i.e. it includes an option to include the source code with syntax highlighting. You can see the output for Classpath 0.97 online.

JikesRVM is also stepping up for a new release, 2.9.3, and this will be the first to showcase the new Classpath support for a non-copying unsynchronised StringBuilder. This is designed for local method usage where the builder will be converted to an immutable String object rather than leaving the method. As a result, I’ve been rushing to get it in a releasable state, as I know there’s a nasty bug lurking in the older patches JikesRVM has been using recently. I managed to do this today after we fixed a build issue. It seems the javah in OpenJDK6 outputs differently named header files to those JikesRVM implicitly depends on. We fixed this by making this dependency explicit as it should be, but perhaps this also uncovered an OpenJDK6 bug. I’m not sure where we should be filing these yet, so I just posted to jdk6-dev.

It’s also nice to hear that Ubuntu has just shipped with IcedTea6 included. Fedora 9 will also ship early next month (May 13th) with similar support and an OpenSUSE build is in the works. It’s nice to see Java support making it into the mainstream, thanks to Sun’s recent moves to make their JDK Free Software. On the less positive side, it seems that Gentoo won’t see support for IcedTea6 anytime soon. The Java Gentoo developers seem to be on a strange mission to support only the proprietary Java solutions (pretty much an inverse of what Fedora, Ubuntu and Debian do). In porting my IcedTea6 ebuild from the Libre Java overlay to their own overlays, they seem to have decided to drop support for GCJ… I’m not even going to go into how dumb this action is, as I could be here a while. Suffice to say, I don’t see how IcedTea6 can be bootstrapped without GCJ, let alone how they expect to then build it on architectures like PPC, PPC64 and ARM, as we’ve seen happen on the OpenJDK distro mailing list. It seems a very odd move for a distribution supposedly built on compiling things from source…

As those who’ve had the unfortunate luck of being in our IRC channel over the past few days will know, I’ve been trying to build IcedTea6 on our Debian etch server again. The good news is it looks like I may have succeeded this time, with some help from Christian Thalinger (twisti) and Gary Benson (gbenson).

Basically most of the tools that come with etch will be useless in your task. The versions of Kaffe, GCJ and GNU Classpath+JamVM that come with it don’t support the 1.5 language extensions. To add insult to injury, because the gcj backport used by Fedora is ‘4.1′, IcedTea won’t scream at you for a default ./configure; make. Instead, the OpenJDK sanity check will tell you that you don’t have a 1.6 VM to bootstrap with (although you only actually need a 1.5 one…). This is because IcedTea will symlink bootstrap/jdk1.6.0/bin/java to the gij that is part of etch, which reports itself as 1.4. Similarly, the jar file it picks up is a pre-generics version of Classpath that can’t be used even with a VM that claims to be 1.5.

So you need to build your own Classpath Java stack before proceeding with trying out IcedTea6. This machine is used to do my regression testing for Classpath so I already had an install of 0.97.1, but it’s simple enough to get a copy of GNU Classpath and a compatible VM if you don’t. You CAN use what is installed with etch to build this. The simplest way to do that is to install the java-gcj-compat-dev package which should give you a native version of ecj.

Using this, you can download Classpath 0.97 or any prior version up to 0.95 (the first to include the code merged from the generics branch). ./configure; make; make install should work, but you probably want to use --prefix to install it in a local directory rather than /usr/local/classpath. --disable-plugin is something I also usually add to avoid having to had the Mozilla headers.

Once installed, you need to add a 1.5 VM that works with this. CACAO (from the Mercurial repository), JamVM or the new Kaffe release should work. I used CACAO. You can then configure IcedTea6 by pointing it at the new install. Assuming $CLASSPATH is where you installed everything:


./configure --with-java=$CLASSPATH/bin/java --with-libgcj-jar=$CLASSPATH/share/classpath/glibj.zip --with-jar=$CLASSPATH/bin/gjar --with-rmic=$CLASSPATH/bin/grmic --with-javah=$CLASSPATH/bin/gjavah


Before building, you also need to patch glibc (thanks to twisti for this tip). Don’t worry! It’s not too scary, just a simple change to a shell script, to make it the same as in more recent versions. On x86, the change is in /usr/lib/libc.so. The last line should read:


GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED (/lib/ld-linux.so.2 ) )


If you’re on x86_64 or ppc64 (or any 64-bit platform i guess), you need to patch /usr/lib64/libc.so:


GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld64.so.1 )


That done, you should be able to run make and hopefully reach the message that IcedTea is served. YMMV of course, so let me know how you get on. This was quite a bit easier than when I last remember trying, so hats off to the IcedTea folks for all their hard work. Next stop, Solaris…