GNU Classpath


Just got back from FOSDEM 2007 in Brussels; it was really nice to meet you all and put some faces to all those nicks I’ve seen on IRC. I see Steph already put up some great pictures from the event, and that Simon’s keynote is on-line as well. I have a few things on my own camera as well, that I’ll hopefully get round to pulling off too later.

The main subject of this blog is something I wanted to post about before I left, but didn’t get chance (I really should update this thing more often– it seems I’ve had over 1000 horrible spam messages since I last played with it). It seems the Fedora team are heading for Core 7 fairly soon, and only realised recently that this will include the new gcj with 1.5 support; great news :) Or it least it would be if this didn’t mean those guys ended up being the first ones to take the thing public, and thus found bugs that had been lurking on the generics branch for a while…

It also sees some of my management work going out in a release, which I wasn’t expecting until Classpath 0.94. Some of it really needs more testing, and this means it ended up getting dumped on the Fedora team… whoops. My apologies and thanks to them for this, and in particular, Gary Benson, who has found and patched a number of bugs in that code while trying to get it working with Tomcat.

The most strangest of these highlights an interesting issue with Java’s typing. If you pass a character to a method, and it turns out that there isn’t a version of the method that accepts a character, but does accept a larger integer type (such as int), then the character will be safely cast to that type by the compiler.

Some of my management code fell over this when instantiating a StringBuffer, which can’t be instantiated with a single character (strangely), but can take an integer as its initial size. So my call to new StringBuffer(‘”‘) was allocating a buffer of length 34 rather than setting up a new buffer containing the character ‘”‘. It’s an interesting issue, and it makes me wonder if this has cropped up before. It would be nice if StringBuffer got an additional constructor which does take a character in order to solve this.

Update

Mario’s pictures are now on-line as well.

Over Christmas, I’ve begun attacking some of the low-hanging fruit for 1.6, which largely involves making most of the main packages, such as java.util, up to date. I started by updating java.lang.management, which was annoyingly nearly at 100% when 1.6 came out, at which point it slumped by about 20%. However, I can now say with some pride that we do have 100% of this at 1.6 level.

I then went on to update some of java.util. Most of this was fairly simple. In tackling the Collections API, the new Arrays methods were notably simple. The main issue was the laborious job of updating TreeMap; the implementation was fairly easy (most of it was just wrapping existing stuff to fit the new APIs) but this did require adding a few more inner classes.

Currently, I’m wrapping up with the new service providers. It’s now finally possible to have external locale information via a service provision mechanism, in the same way that image and audio formats have been supported in the past. I actually started on this to some extent by accident; I was adding a couple of missing methods to Calendar, and ending up calling a DateFormatSymbols method we didn’t actually have. I’m now actually at the point where I should be able to remove the FIXME from the current implementation tomorrow, and replace it with some code to probe for appropriate service providers. However, this does bring in new classes, which as Stuart points out, mean a lot more to JAPI. Hopefully, tomorrow’s results will reflect this…

Once this is over, I’m heading back to the management stuff. This is the main hole in our 1.5 support, AFAICS, so it would be nice to get that plugged.

Update

I was right… our JAPI scores went up by 0.05% against 1.6, which is the most so far from this hacking session.

You read the title right; the trunk of GNU Classpath now contains the contents of what was the generics branch. You’ll now need ecj to compile, and we should really be supporting javac too (which should be compilable with current CVS, I hope)

Probably too early to say if there were any problems with the merge, but the actual transfer of code from generics to HEAD actually went very smoothly; a completely clean patch, and it built successfully at the first shot. What took time was getting generics back in sync, which always takes a while after a release, as the generics branch is in sync with the release branch rather than HEAD.

Please let me know ASAP about any regressions and such. CVS is back in business, so please start hammering the code and committing stuff again! As Mark says, please go nuts!

Woah! What a day! For those who don’t already know (due to living in a small cave in Outer Mongolia), Sun today announced that it will be releasing J2SE, J2ME and J2EE under the GNU GPL. What is especially exciting about this is that the class library, which will be released early next year, will be out under GPL+Classpath exception, the exact same license used by GNU Classpath, thus allowing a beautiful merging of codebases… (we hope).

So it follows that I’ve been somewhat distracted today, following the webcast and chat conversations on this stuff. Also, the release of javac today under the GPL was too good an opportunity to miss — we had to get this working with GNU Classpath and friends! Unfortunately, it seems Sun don’t follow their own advice, and the code has references to sun.* stuff. But a bit of mad-cap hacking soon sorted this. To build your own javac with ecj, GNU Classpath generics branch and a Free VM, follow these instructions:

0) Compile a modified version of the current generics branch by including the stubs in this zip file.
1) Download the Sun javac source tree using svn checkout https://openjdk.dev.java.net/svn/openjdk/compiler/trunk –username guest
2) Build it using your favourite technique. I found it easiest to just hack the Makefile to use my own script for running ecj:

#!/bin/bash

ecj -1.5 -bootclasspath ~/projects/java/classpath/generics-build/share/classpath/glibj.zip $@

and then used make. Make sure that ecj is using the generics branch that you compiled earlier.
3) With luck, you should get a set of classes in build/bootclasses.

Problem then is that nothing will actually run the compiled javac — well, to compile stuff anyway. jamvm can at least get the config info and the version number:

$ jamvm -cp ../trunk/build/bootclasses:../trunk/src/share/classes com.sun.tools.javac.Main -version

javac 1.7.0-opensource

It fails when it comes to compiling and the annotation stuff fails with our regular expression implementation. Someone up for some hacking? gij (gcj-eclipse branch) fails earlier with a NullPointerException in a call to EnumSet.of() — I’m guessing this is due to the FIXMEs in isEnum()…

Anyway, I think this is a good start. Next, we get the VM to run with Classpath… ;)

Update

The regex problem was simple to fix, and I’ve committed a patch to the generics branch. jamvm now fails due to a missing implementation of sun.misc.Unsafe:

java.lang.UnsatisfiedLinkError: objectFieldOffset
at sun.misc.Unsafe.objectFieldOffset(Native Method)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.(AbstractQueuedSynchronizer.java:2124)

Any VM have this yet? I think gcj-eclipse does, but lacks isEnum… (or maybe I just need a newer version???)

Seems like it’s again a month since I last blogged here… :( I’ve been a little outside the GNU Classpath sphere lately, and I really need to get back in the fold. Things have been a little crazy in real life, recently. At the beginning of the month, I had laser surgery, which slowed things down for a week or so afterwards while I recovered. Things have also been busy with the start of the new academic year here in the UK, and teaching duties once again starting up. I seem to be on top of things again now though, and hopefully will commit a bit more soon. I certainly need to do a merge tomorrow……

As a closure to Summer of Code, I went down to London to visit Google yesterday. It was an enjoyable experience, and certainly very interesting. The whole place is kinda like what our PhD research lab would be like if we had about ten times the space and a few million to spend… ;) I came away with a bag full of goodies, and some interesting insights. I’ll also be involved in Google’s Pizza ambassador scheme, once the European side gets going, and I plan to have another stab at SoC next year. It’ll be earlier than last year, probably sometime in February, so need to think about this sooner rather than later.

So it’s been more than a month since I last wrote here. Things have been a bit mad lately with my other life as a postgraduate student. I attended a conference in Manchester at the end of August, and then had to write a report (currently at 90+ pages) on why they should let me stay on for the next two years. So there’s not been much time left over for Classpath stuff unfortunately… it’s kind of good that SoC ended when it did after all.

Over the last week, I’ve added some more of the management stuff, trying to finish off large parts of the JMX stack. Primarily, I’d just like to get the server side of java.lang.management sorted (it still needs to reach 100%). It’s getting closer, but there’s still a fair bit to add.

The talk seemed to go well on Thursday, and we got a good turnout, considering it’s the summer here in the UK (although the weather makes that debatable) and many people are away. I’ll post the video I recorded shortly, once I’ve had chance to edit it.

The visit also gave me a chance to find out about the research being done over in Manchester which relates to GNU Classpath, and plenty of good ideas came from my discussions with Ian Rogers and other members of the department. Hopefully, this will mean more good stuff for the project…

This Thursday, I’ll be giving a seminar in Manchester in relation to GNU Classpath and its handling of the new language features in Java 1.5. I’ve included the contents of the e-mail about this below, and I’m also attaching the slides — comments welcome.

BTW, It seems SoC ends even sooner than I thought — just next Monday! (the 5th is the evaluation deadline). Now that Tom Tromey has merged our branches together, I need to add a bit more meat to the native management stubs that exist. The Classpath side has been a definite success, resulting in over half of javax.management being developed, all of javax.management.openmbean and the majority of java.lang.management (all but the bean server is complete).

———————————————————————————————————————–

“GNU Classpath and Java 1.5.0″

Thursday, 17th August 2006, 2:15pm

Lecture Theater 1.5, Kilburn Building

The APT group is delighted to have invited Andrew Hughes from the GNU
Classpath project to present on Thursday 17th of August. GNU Classpath
is the core library of most open source virtual machines and the GNU
Compiler for Java, part of the GNU Compiler Collection (GCC). Andrew is
the maintainer of the generics branch of GNU Classpath, this project
will allow open source JVMs to implement the richer language and API
features of Java 5.0.

Abstract
======

The GNU Classpath project focuses on creating a clean-room
implementation of the class libraries used by virtual machines and
compilers for the Java programming language, under a Free Software
license. The recent additions to the Java programming language in
version 1.5 have introduced new issues for the project, due to the
necessity to introduce changes across the board, in the compiler, the VM
and the library itself. In this talk, I will briefly describe the
changes made to the Java programming language in version 1.5, and then
show how developers on the GNU Classpath project, and associated
compiler and VM projects (such as Kaffe, GCJ and JikesRVM) have worked
to ensure that there can exist a Free implementation of this material.

Biography
========
I’ve been a developer on the GNU Classpath project for just over two
years. During this time, my work has focused on maintaining the
‘generics branch’ of the project, which attempts to handle the changes
in Java 1.5. Recently, I’ve also been involved in a Google Summer of
Code project. This was also related to GNU Classpath, but focused on
bringing support for the low-level management features in
java.lang.management to the project. My work on the project takes place
in what spare time I have available, aside from my commitments to the
postgraduate degree I’m currently undertaking at the University of
Sheffield, in the area of process algebraic research.

I checked the finish date for SoC the other day and realised that it is in fact quite close; only September 5th. It seems to have lasted hardly any time at all.

As far as my project goes, the Classpath side is largely complete. Each bean is now a fully paid up dynamic bean, that can be probed for its attributes. They also return a descriptor using a limited set of open types, and provide conversion to these types in an implementation of getAttribute, which overrides the one in StandardMBean.

As part of doing this, javax.management.openmbean has become 100% complete according to JAPI, which is a nice indication of the work done. java.lang.management is also approaching this; we just need a platform server now. Unfortunately, it will never reach 100% on HEAD until the generics branch is merged in, as 12% accounts for an enumeration (which seems to weigh quite a lot, but then it does have both its own methods and all those derived from Enum and Object, none of which I had to write).

The gcj-eclipse-jmx branch is nearly in a buildable state. All the build problems I’ve had are now sorted, and I’m actually at the point where the errors are clear linking errors, caused by missing native methods (of which they are quite a few, due to the introduction of the concurrency stuff too). It should be usable soon, and it already includes a working implementation of the runtime bean.

Again, it’s been a while since I blogged, so time for another update. The current status is quite different from the last time I wrote. Classpath CVS HEAD now includes implementations of all the beans, with VM interfaces, and is just awaiting a few finishing touches that require stuff from the javax.management blob of packages (which are slowly getting implemented on a as-needed basis). Last week, I added support for the open management bean CompositeData class, and a translation from instances of that into instances of ThreadInfo and MemoryUsage. Today, notification support was largely added; all that is needed now is to implement the bit in the memory bean that actually implements the required interface and creates appropriate instances on a callback from the VM.

After that, the beans need to become real management beans (i.e. implementations of DynamicMBean really), and then be made available via an MBeanServer instance (the platform server). This will require most of the rest of javax.management, I guess, and javax.management.openmbean. I think the rest can wait until the SoC project finishes.

On the GCJ front, the copyright issues were sorted out, and I now have a branch: gcj-eclipse-jmx, which is based on Tom Tromey’s gcj-eclipse branch, but with a more up-to-date copy of the generics branch, including the management changes. I currently have a implementation of the Runtime bean on there, but things aren’t really buildable at present. Still a fair bit to sort out, but certainly things seem feasible in the time remaining.

« Previous PageNext Page »