April 2008


For those who haven’t yet heard, Richard Stallman will be doing a rare UK talk tomorrow in Manchester.

‘Free Software in Ethics and Practice’ – speaker: Richard Stallman

Thursday 1st May, 2008 – Talk starts at 6:45pm (ends approx. 8:30pm) with refreshments from 6:15pm.

Venue: Room D1, Renold Building, University of Manchester, Sackville Street, Manchester M1 3BB

http://manchester.fsuk.org/blog/

I’ll be there, fingers cross, and hopefully I’ll also be able to record the event.

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…

Over the last week, I’ve been getting Gentoo and Free Java up and running on my new x86_64 box, a process which has culminated in the creation of my own overlay:

http://fuseyism.com/hg/libre_java_overlay

For those unfamiliar with Gentoo, an overlay is an additional set of packages (known in Gentoo as ebuilds, as for a source-based distribution the packages are essentially build scripts) which can be placed over the top of the main system tree to provide newer/better versions of existing builds and completely new ones too.

The Libre Java overlay includes a build for GCJ 4.3 (adapted from the one for an alpha snapshot in the java-gcj-overlay) and one for IcedTea6. Unfortunately, Gentoo’s Java support seems incredibly broken — the main stable and experimental (~) distributions don’t include OpenJDK or IcedTea, and the stable versions of GNU Classpath and VMs like CACAO and JamVM are ancient. GNU Classpath is still on 0.90, which is older than the one in Debian stable. It also tries to pull in the proprietary JDK by default; I recommend Free Java Gentoo users add:

dev-java/sun-jdk
dev-java/ibm-jdk
dev-java/jrockit
dev-java/diablo
dev-java/sun-jre-bin
dev-java/blackdown-jdk

to package.mask to avoid accidentally installing proprietary software on their machines. Unfortunately, stable versions of portage have yet to honour any license scheming, although it is in the unstable version. If you use Gentoo, feel free to try out the ebuilds from my overlay and give feedback. To use it, just get Mercurial (emerge mercurial), clone the repository:

hg clone http://fuseyism.com/hg/libre_java_overlay

and then add the following to /etc/make.conf:

PORTDIR_OVERLAY=<location you downloaded libre_java_overlay to>

The build process for IcedTea6 is fully documented on the IcedTea wiki.

Having just read Andrew Cowie’s recent blog, I wanted to comment but couldn’t find an option to do so there. So here it comes here on my blog instead…

Simply put, OpenJDK is so named because it’s a FOSS version of Sun’s JDK the implementation, not Java, which is the specification. Just because OpenJDK is the reference implementation doesn’t mean it is the specification as well. The equivalent would be calling Tomcat OpenServlet (it being the reference servlet implementation). This also reflects on the comments about the HTTP server being in com.sun. This is because it is part of Sun’s implementation and not part of the Java specification. To become part of the specification requires a JSR and interaction with the JCP which are distinct and separate from OpenJDK. That’s the process that would result in java.net.httpserver (or, more likely, javax.net.httpserver because it’s not an essential part of the core).

I hope that clears things up. I’m really happy OpenJDK has found an interesting alternate use that clearly demonstrates the benefits of the FOSS implementation over the proprietary one, and thanks for blogging on this. Now you should go build IcedTea… ;)

I read Mario and Roman’s posts this morning and they inspired me to post too, after realising that there was a lot of stuff that’s been going on that I also hadn’t blogged about. Firstly, Google Summer of Code closed its doors to student applications on Monday (well Tuesday really, here in Europe) and we were rather disappointed to find only two applications for GNU Classpath, both for java.util.Scanner. This is a real pity, as I think we had some really good ideas on the list (and even more interesting ones were left to one side after AICAS didn’t get in as a mentoring organisation).

I think students picked Scanner because it’s used on many undergraduate courses these days (something of which I was blissfully unaware, as it’s years since I did any introductory Java course or read an introductory book). Unfortunately, the future of such an idea is really dubious, as I explained to our first applicant online, as there is already an implementation (no idea how good or complete) by a student of Christian Thalinger (twisti) which we hope to get into the codebase, once the legalities are sorted out. Equally, we are looking at using BrandWeg to get the OpenJDK version; this has only really ground to a halt because I found we’d need to either update our regex implementation or also bring in the OpenJDK one and I simply haven’t had time. Again, BrandWeg was on the ideas list, but no takers :(

Personally, I’ve mainly been looking at IcedTea recently, in preparation for the OpenJDK challenge work. I haven’t really blogged on the details of this yet, but my first port of call will be to take an OpenJDK/IcedTea build and attempt to get the class library from that to work with one of our Free GNU Classpath VMs. Rather than trying to build the Sun interface into that VM, I want to use that process to figure out the best way to create a more well-documented VM interface including support for VMs that don’t want to go the native route for the VM interface. I intend this to be an interactive process so I’ll be posting results and hoping for feedback as we go along. As the OpenJDK challenge infrastructure gets sorted, I expect this will take place under the auspices of an OpenJDK project. I’ll be tagging appropriate blogs with the ‘VM interface’ category so feel free to track them.

One question that does spring to mind is whether the challenge projects are intended to work with OpenJDK or OpenJDK6. IcedTea work has pretty much shifted to OpenJDK6 (in the form of IcedTea6) with good reason; distros want to ship a stable Free equivalent to JDK6, not an early alpha of JDK7 (which doesn’t yet even have a JSR attached to it). Ideally, I think we should maintain both, as the IcedTea porting process seemed to suggest the differences weren’t too major. But feedback here would be welcomed. I’d also like to make the new VM work easy for others to test, so hopefully some integration with IcedTea will be possible there too. I’m very impressed with IcedTea so far, especially Gary’s zero port (as my previous blogs hopefully illustrate). There are some niggles, but lots of eyes and people testing it in different environments will fix these. It’s great to have OpenJDK on PPC64 for one thing!

To close, I notice that people are moving around in the Free Java world (as my reference to Mario’s title in mine hopefully indicates). First, Tom Marble left Sun earlier this year, and now we find that Dalibor has successfully stepped into his (hopefully clean) shoes. To me, there doesn’t seem to be a more appropriate replacement, though it does make his governance board position interesting… Mario has also now moved to AICAS, so it seems like most people are getting new jobs and different roles in the new Free Java world brought about by OpenJDK. Things will change for me as well soon, as I’m due to finish my PhD here in October (well the funding runs out at least, which means I need some alternate source of cash at any rate). So it will be interesting to see where I am in a year from now too…

Some good news on Wednesday:

IcedTea is served: openjdk/control/build/linux-i586

$ java -version
java version “1.6.0″
IcedTea Runtime Environment (build 1.6.0-b08)
OpenJDK Client VM (build 1.6.0-b08, mixed mode)

IcedTea is served: openjdk/control/build/linux-ppc64

$ java -version
java version “1.6.0″
IcedTea Runtime Environment (build 1.6.0-b08)
OpenJDK 64-Bit Core VM (build 1.6.0-b08, interpreted mode)

As an addendum to my previous blog, Debian Etch needs a backported Freetype to be able to build IcedTea. I’ve finally made my x86 backport available.