Some good news. It turns out it wasn’t my build of the RVM that was buggy, but rather a case of JikesRVM being too clever for its own good. Observe the name of the class I was trying to load:

gnu.classpath.examples.management.TestClassLoading

Its prefix is ‘gnu.classpath’ which is also used for some of the core classes. JikesRVM only tries to use the bootclassloader if part of the class’ full name (with package) contains one of the packages it considers to be one of the core packages. In full, these are:

private static final byte[][] bootstrapClassPrefixes =
{“Ljava/”.getBytes(),
“Lorg/jikesrvm/”.getBytes(),
“Lgnu/java/”.getBytes(),
“Lgnu/classpath/”.getBytes(),
“Lorg/vmmagic/”.getBytes(),
“Lorg/mmtk/”.getBytes()};

It makes a lot of sense, but is a bit too strict. You’ll note that javax isn’t there, even though a lot of the library classes are in that package (JMX itself for one, along with Swing) and it is one of the prefixes Sun disallows being used for external classes. Why? Because lots of extensions wouldn’t work if it was.

So that line stops the Classpath examples working, and I’ll be patching it on my new JMX branch:

https://jikesrvm.svn.sourceforge.net/svnroot/jikesrvm/rvmroot/branches/RVM-127-JMX

and submitting a patch. I’m not going to remove it completely, but instead be more specific and specify the appropriate residents of gnu.classpath that should be blocked. I’m thinking in the long run it might be nice to have this automatically generated during the build if that’s possible.

I’ve just found that it generates another problem. It stops the VM being self-hosting because it can’t run its own Ant task:

BUILD FAILED
/home/gandalf/projects/java/classpath/jikesrvm.jamvm/build/tasks.xml:28: taskdef class org.jikesrvm.tools.ant.ForEachTask cannot be found

org.jikesrvm, you’ll note, is another disallowed prefix.

OpenJDK

I’m still fairly disappointed with the way OpenJDK is proceeding, and I read Roman’s comments this week with interest. At least it’s not just me that feels this way. I guess it’s just that we’re impatient, but especially with the release of the code, we GNU Classpath hackers feel we want to do something to help.

Just looking at the speed with which IcedTea has developed, it’s clear that the motivation is there. However, there’s a missing link. There’s no way of feeding stuff back in to the OpenJDK project, no live source repository and an unknown bunch of Sun developers working on the same stuff. At some point, their code will appear in one of these ‘b’ source code drops and whatever we’re doing will be rendered obsolete.

Meanwhile, work on GNU Classpath has ground to a halt because there’s no motivation there any more. Why bother implementing a package when the GPLed code is out there in the OpenJDK? But there’s currently no way of joining the two together to create a Free Java implementation. I feel we’re still just as far away as we ever were, with a future much less bright at the moment. I’ve had a fantastic three years of working on GNU Classpath, and through that time the development pace has increased to an unbelievable rate and I’ve met some truly fantastic people.

I’d hate to see the results of this work go to waste. But right now is the most indecisive and scary time I’ve been through while working on the project and I just don’t know what will happen next. The current OpenJDK is in a worst state than Classpath (I’m talking about IcedTea, I don’t consider the version with binary safety pads a Free Java) and the fantastic work coming from the RedHat guys seems a little like stuff we’ve already done in Classpath.

Here’s to better times ahead.. I hope.