GJDoc


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…

Well it’s now 2008 (unless you’re in the US of course) and traditionally a time to reflect upon the year just gone. Well, it’s certainly been one of movement and change in the GNU Classpath community, if also one of very little code hacking. Of course, the biggest event of the year was the release of the OpenJDK source code in May; about 95% of the JDK source code base was made available under the GPLv2, the rest both then and now being filled by binary blobs, which are slowly decreasing in number.

However, back in January 2007, we were still waiting for this to happen. As I recall, we’d just (gone through the generics merge, migrating the contents of the branch on to the main tree and over the Christmas period I added quite a lot of 1.6 code. Sun’s javac compiler was open-sourced however, as part of the November announcement, and we soon had support in GNU Classpath for building with it.

In February, GNU Classpath was again at FOSDEM and I finally attended after missing out on the last two years. It was good fun and notable for our collaboration both with the DevJam folks and the OpenJDK community (AKA Sun). Everything was very much still ifs and buts however, because I don’t think anyone knew what would really happen when the floodgates opened and the JDK was released. Of course, GNU Classpath will again be at FOSDEM this year, and apparently with even closer collaboration with OpenJDK — try and even spot a mention of GNU Classpath on those pages… Hopefully, I’ll be there again too.

The year only saw two Classpath releases, which is sort of representative of its ongoing decline I guess. 0.95 was released shortly after FOSDEM in April, a delayed and very necessary release which include the generics move and the other stuff I mention above. Getting a GNU Classpath release out the door has become more and more of a struggle over this year and, in a way, has become synonymous with a pregnant mother giving birth, as a team of developers stand round screaming ‘push’ until eventually the release emerges. Our release of 0.96 in October certainly felt like that to me anyway. On that note, congratulations to both Michael Koch and Roman Kennke who both (or should I say, their respective partners) had children this year.

May of course saw the release of the OpenJDK source code and the inevitable hordes jumping on and pulling it about took place with the same speed and haste we saw on the release of javac. This has eventually surfaced in the form of IcedTea from a number of GNU Classpath/RedHat folks, a build framework for the OpenJDK which, most importantly, serves it without the need for proprietary code (given that the current OpenJDK build has no real advantage over a proprietary JDK drop unless you want to tinker). This was produced by splicing in bits of GNU Classpath code. It’s a whole deal more easier to use than plain old OpenJDK but still not a walk in the park. This is especially true since Sun split up the build process and made parts of it depend on Ant

It’s quite sad to say, but OpenJDK is still not what we all hope it will be. Thankfully, live Mercurial repositories are now available as of December, but there are still too many walls, as I mentioned before. It’s like the JDK was something that popped out of a little black box, but now someone has taken the lid off the box so you can see the little worker ants running around inside and making it all happen. But there’s not yet anyway to get inside the box ourselves. New ants need to be able to join in the fun. We’ve already seen one of the goals I mentioned in August realised (the open repositories), and hopefully more will change in 2008. Sun’s innovation awards are both a realisation of this problem (common to both OpenJDK and many of its other open source projects, which still have a predominantly Sun ethos) and hopefully its saviour.

It smells a little like Google’s Summer of Code and indeed Tom Marble was asking myself and Mario about this on IRC. This year of course saw me tackling JikesRVM for GSoC, trying to implement the VM-level management extensions. A lot of this work was done, and following GSoC, I was made a member of the JikesRVM team. However, the patches still haven’t gone in to the mainline, due to a combination of the release process (some of these are likely to be destablising) and finding time myself to test the stuff on the main branch. This hasn’t been helped by a re-emerging problem with building JikesRVM using Classpath; this same problem plagued my initial month or so on the project when I discovered it seemed to rely on proprietary software to work…

So altogether it’s been an interesting year. Not only have I worked on both the old (continuing with GNU Classpath and also pushing out a release of GJDoc) and the new (launching the IcePick project to build the OpenJDK tools separately) over the last year, but I’ve also sadly seen the community enter something of a demise as people start to move on to other things, especially IcedTea and OpenJDK. What will 2008 hold? Maybe I’ll find myself working on OpenJDK too…

Now that SoC is finished, I’m looking at what to do next and a lot of things within the Free Java world are competing for my attention. Primarily, we need to get another Classpath release out the door as 0.95 was released in April. There have been quite a few bug fixes since then, and it would be nice to make these more widely available. Also, we plan on releasing a new version of JikesRVM pretty soon, and it really should ship with the latest Classpath. One issue that I believe should be fixed in CVS (e-mails this week seem to be saying something to the contrary) is buidling using OpenJDK’s javac. For JikesRVM, this would mean it could drop its dependency on downloading, building and using ecj. A plan for this is now on the Classpath wiki.

On the subject of JikesRVM, I’ve now been made a member of the core team and I’m working towards integrating the JMX stuff (still on the SoC branch) into the main tree. For the imminent release, I think this will just be the parts that don’t impact too heavily. There are some changes to the threading code involved that I think need to wait until post-release and more review/performance testing.

In the long run, I’d like to see Classpath being able to run JConsole, which means supporting the remote part of the JMX specification. This should hopefully mean a new blast of code into the Classpath repository which has been dormant of late. I also need to look further at IcePick, merging my work on building the Java tools (javac, javadoc, etc) with Dalibor’s SoC work for javac. There’s also more work that could be done on GJDoc, if we’re still maintaining that, and I’d like to look and see if there’s anything that I can do to contribute to OpenJDK yet (the modules stuff Dalibor mentioned to me looks interesting). Lots to do, I should file a bug request for a 48-hour day enhancement…

We now have two FOSS 1.5-capable compilers: ecj and the openjdk version of Sun’s javac. Both clearly have parsers for this version of the language, which got me thinking as to whether we should simply depend on one or the other (maybe even both) to provide parsing for gjdoc. I’ve looked at the OpenJDK code so far, and this seems fairly feasible. I’ve yet to look at ecj. In the meantime, I’d be interested to hear people’s opinions on what they think best. Clearly using one of these is a dependency we have to introduce, but, if we switch to 1.5 source code, this will be required anyway. It also removes the dependency on the lexer/parser framework we use (name escapes me right now…). As I see it, there are four options:

  • Retain the current parser code and update it for 1.5. Given the state of this code, it’s likely to be something of a headache, and likely to remain fairly unmaintainable in the future.
  • Replace the parser with our own generated using the tool we currently just use for expression parsing. Seems a little redundant as there are already capable parsers available.
  • Depend on either ecj or OpenJDK javac for parsing.
  • Use either ecj (if feasible) or OpenJDK for parsing, depending on which is also used to compile.

Any feedback is much welcomed.

I’ve also started to look at JikesRVM for SoC and run into some issues just trying to build it. Seems that not all is Free in the JikesRVM world and I can’t even build on a Free Java stack. My first trauma was trying to get ant (now used for the build system) to find a Java compiler. I couldn’t seem to get it to talk to ecj, so I pointed it at the JAR file for OpenJDK as an apparent ‘tools.jar’. I then ran into problems a few steps in, where it tries to use apt (the annotation processing tool, not the Debian package manager — which could have been interesting…) to preprocess some code. We don’t have an equivalent in Classpath, and it appears this is deprecated anyway in 1.6, in favour of javax.annotation.processing and capabilities in javac. Changing this is something we’re just beginning to discuss on the mailing lists, but it seems to be accepted that Sun or IBM is needed to build… ick. It seems there was some Kaffe support earlier, but it has gone the way of the dodo (along with its reference in the user manual). Ian Rogers has kindly supplied me with the file that is generated by this apt stage, so maybe I can at least see what hurdle comes next… Makes me think I should have made the project ‘Liberating JikesRVM’…

_
_
_
_
_
_
_
_
_
_
_
_
_

So, last week was quite eventful. Firstly, I got accepted for Google’s Summer of Code, working on the Jikes RVM project. I’ll be continuing in much the same vein as last year’s GSoC in implementing the java.lang.management extensions. It gives me a good excuse to finally play around with Jikes RVM again. The last time I tried was several years back when I first started hacking on Classpath, and I fell a victim to its build system, never even getting a running VM out of it. The build system has since been seriously re-jigged, so this time I intend to have more success. At least this time round, I know who to talk to if I don’t…. ;) Implementing the extensions on a VM is a good way to get to know the ins and outs, as it requires some fairly deep hooks. Hopefully, I won’t cause too many ruptions in the codebase…

Other than that, I’ve been playing around with GJDoc, trying valiently to get it to eat the latest Classpath CVS source. I finally succeeded in getting a run through last night, and the results are available on my website. File your bugs in the usual place; believe me, there are plenty!