Kaffe OpenVM
It's been a busy month. I fixed the remaining issues with parisc-hpux by closely following in Helmer Kraemer's footsteps, and with a lot of help from Riccardo Mottola testing my patches. Turned out that mprotect on hpux only works on mmapped memory, and that was the major problem.
Kaffe 1.1.2 was released earlier this month, and again, the usual tide of patches and bug reports came in. Among the more interesting ones, there is recharged interest in getting kaffe to run with mozilla. Aleksandr Abakin has taken the old kaffe-mozilla-oji-lugin code, and updated it to work with mozilla 1.3. He's still fighting with some bugs, though. Supreet Sethi is working on getting a gtk based AWT backend to work with kaffe. It seems that people look at the FTP server and try things out they find near the downloads of a new release, and attempt to fix them. Amazing. We should put more half-finished projects close to our releases ;)
More code has been merged in from GNU Classpath: java.beans, and java.util.jar packages. Java,util.zip is half done. I 'd like to have a Zip Inflater/Deflater SPI, that would allow me to use both pure java and native implementations of Inflaters and Deflaters.
Among the recent success stories, JBoss 3.2.2 loads on kaffe from CVS. Getting the beast to work will take some effort, and contributors are welcome. Having JBoss run on kaffe would mean having a fully free J2EE environment to work with.
On another J2EE front, I'm in touch with OpenEJB developers to try to get that J2EE implementation running on top of kaffe. It currently fails due to some bugs in OpenEJB, that does some pretty ugly (read not portable java) things to work around some limitations of Sun's VM. Which brings me to my rant.
Burn all java code that imports sun.* classes
If you are a Java programmer writing free software, you may have come across Sun's documentation for their programming language. Sun goes to great lengths to explain to people not to use internals of their VM, not to import sun.* classes and so on. A lot of people get the message.
Unfortunately, some people don't get the message. And they all seem to be working on big free software java projects.
Take a look at Java code in OpenOffice, for example. It's a big pile of rubbish that imports sun.* classes almost everywhere. And without reason, as well. Among many pointless lines of code, OpenOffice java code includes a java.util.jar implementation that seems to have been stuck there unmodified before Java 1.1. was released. That was more than 5 years ago, I think.
It causes great pains for those people who'd like to have OpenOffice running on their platforms. As the OpenOffice build system goes, you need a Java VM to build it. Of course, you in fact need some special version of Sun's JVM ported to your platform, as free VMs don't implement any of the undocumented sun.* classes.
Then there are such projects like Ant. Ant, the great make replacement for Java that most Java programmers learn to love as soon as they see it work. The trouble is, many ant tasks are written in really bad, unportable java. For example, for efficiency reasons, ant developers have decided to design for running many applications that one would run in a separate process (like javah) in the same VM in which Ant is running. To do that, as they can't run the applications as Processes, they need to call the main method of those java classes implementing the programs in question.
Sun has anticipated people being keen to use the internals of their implementation, and pulled classes for their externally callable programs into a separate tools.jar, apparently. So you can't import sun.something.Javah and have it work out of the box. But of course, that won't stop determined 'programmers'. So Ant, and many free java programs, depend on Sun's JRE file layout to be able to add tools.jar to their CLASSPATH using the JAVA_HOME enviroment variable, another undocumented property of Sun's VM. I'd spare my JAVA_HOME rant for some other day.
If the programmers in question were as clever in writing their code, as they were in circumventing Sun's java programming recommendations, they would have at least used reflection to check if the undocumented class they are trying to load is available at all. After all, Sun explicitely states in their docs that they consider their internal classes to be, well, internal and reserve the right to change the internals as they see fit. But nope, a job done in an obviously broken way, is still a job done, to some programmers.
And so on: Xerces uses some internal class from Sun to acess CharacterConverter information. But Sun defined an API to do it in Java 1.4. Since a lot of people use Xerces somewhere, a lot of people have stumbled over that one: the bug database has several double entries covering it. Unfortunately, the developers of Xerces are unwilling to fix it.
I hope that the rise of gcj will root out bad java software out there, and no self respecting free software java project will accept unportable java code in a not too distant future. If it won't build with gcj, a project will become insignificant.
GNU Classpath developer meeting at Linux Kongress
Had a great meeting with other free java hackers during the Linux Kongress. We discussed many things, among those most prominently the quite cool Java2D implementation on top of OpenGL by Jean-Daniel Fakete. I hope to be able to merge it into kaffe soon, as it's some 10-100 times faster than Sun's implementation.
