Older blog entries for robilad (starting at number 45)

Helmer and Guilhem are working their way through interesting bugs in the core. I'm meanwhile syncing Kaffe up with GNU Classpath's latest changes, and contributing some small fixes back. Thanks to Eclipse, I got quite a few imports cleaned up, so that's slowly going back into GNU Classpath.

Movies

"Triplettes de Belville" was quite enojable. Good music, straight story, nice refences to Tati, a few good jokes.

Well, tempus fugit, and all that. In the last three weeks we got a few new developers on board. There is doogie, who has almost single-handidly beaten a few thousand warnings into the ground last week. And there is Jim Huang, who's been testing a lot of interesting stuff with Kaffe in preparation for an interesting Kaffe Multi-Media Project.

Thanks to jpick, we've got a release plan for 1.1.5. It's due in three weeks. As usual, there is a ton of things I'd like to see happen before the release. I've been hacking on A,C,F and I from that list, and it looks like I'll be able to get gjdoc into kaffe very soon now, mostly thanks to efforts from Arnaud Vandyck on integrating libxmlj into GNU JAXP.

In other news, Guilhem has been quite busy recently fixing kaffe's kjc, java.text implementation, NIO, and almost everything else he could get his hands on. He's a great hacker to have on board. I was also pleased to see Helmer return with a series of patches, to improve ARM support, among other things, and Ito tracking down a few ugly bugs.

After wrestling with the automake warnings, I decided I had some bigger fish to fry, and went after the gcc warnings. Using some nice autoconf machinery from the AC Archive I extended our configure script to add as many gcc warnings as I consider useful.

The reason for this is that kaffe seems to happily crash on so many platforms. So instead of chasing them all down with gdb, I decided to take a more indirect approach to debugging, and start fixing all the ugly, nasty hacks in our code first, before I even think about wielding the debugger on them.

Of course, the initial results are disappointing yet promising. Today I've only barely scratched the surface of the few thousand or so warnings to fix, but it's fun, in a laid back way. You look at code, try to figure out what the compiler means, and when you notice that the compiler's right, chuckle, and move on to the next fix.

Patch queue is going down, somewhat. I've been wresting with some odd platforms like sparc-netbsd and sparc-openbsd in order to get Kaffe up and running there with the help of Riccardo Mottola. There is some progress, and there are many interesting compiler warnings to look into. Ultimately, this work should result in a better, cleaner kaffe core.

I've also taken a shot at reducing the immense number of warnings autotools (automake 1.8.3 and autoconf 2.59) generate whenever I regenerate the build system. Most of the warnings come from third party m4 files, like the ones distributed with libtool or gettext. So today I wrote a simple script that copied each m4 file to its own directory, renamed it to configure.ac, called autoupdate on it, and moved it back. It mostly worked, except for a bug or two in autoupdate. I'll push the fixes upstream later. but first I want to squish the warnings produced by gettext m4 macros and libtool.m4.

In other news, it seems like SwingWT could run on Kaffe. That would give us another interesting alternative for those applications using Swing.

Gradually working off the patch queue. Some nice stuff is coming in for JNI, due to Jim Huangs inverstigations into running SwingWT and recently JSDL on Kaffe. He's gradually showing up soft spots and solution, thus helping Kaffe's JNI evolve into a good choice for applications that need a little bit of JNI.

Other than that, I've been playing with MIPS2Java, and converted a SPASS MIPS binary into a Java class capable of running on Kaffe. It ran faster than on Sun's JDK for a simplistic test on a pelletier problem. That is quite fascinating to me, since Kaffe doesn't have a hotspot jitter. It's also an order of magnitude slower than the native code. I haven't tried recompiling the class with gcj, though.

As the next step, I took Portable Dot Net from dotGNU, and started (automatically, of course) turning it into java classes, in order to bridge that seemingly huge rift between Dot Net and Java, allowing a Dot Net runtime to run on a java runtime. Like a primitive IKVM in reverse. I've so far managed to convert the tools, and the runtime itself, but haven't started to build the class library, which I expect to be the interesting test if the concept can work, in practice.

While I'm typing this, my fellow GNU Classpath hackers are busy creating and improving a free software Java class library that's not only licensed under more reasonable terms then the non-free implementation, but also rivals it in terms of performance and aims to be the better choice in the long run.

Almost every free software implementation of a Java runtime out there (and a few non-free ones) is using GNU Classpath as the Java class library of choice, including even IBM's own JikesRVM. The progress GNU Classpath has made in the last year alone through this immense cooperation effort is mind-blowing. Nowdays, you can not only run tools like Ant or Tomcat on free runtimes like Kaffe OpenVM, you can also run complex enterprise applications like OfBiz and Eclipse.

If people write *portable* java code, and stick to the implemented classes or work together with the GNU Classpath developers on implementing the missing bits, like Havoc suggests, I think free java runtimes could turn 'write once, run anywhere' from an over-hyped marketing joke into reality.

Unfortunately, some open source java projects don't write portable code. They use internal classes in sun.* packages, which makes them about as portable as Microsoft applications using undocumented Win32 functions. Some people write code that only works because their unwritten (and often unwarranted) assumptions about the runtime their code was written on held true. It's the same with C, or C++: writing portable code takes care in any language.

But, the good thing about the free runtimes is that they can take Java applications where no other runtimes can take them: you can compile things down to native code, run it on non-mainstream platforms like embedded PowerPC chips without an FPU, combine Java code with .Net ... And the great thing about it is, that most of the free Java runtime developers are not building their own little lock-in solutions, but are instead cooperating on creating a larger playground for everyone, by sharing knowledge and code.

I boldly predict that Java-Gnome on free runtimes will rock the Linux application world in the years to come. Java-Gnome applications are going to make sure free Java becomes a success on the desktop. Free software enterprise applications like OfBiz, JBoss, Jonas etc. will do the same for the server side. The major stumbling stone right now is the unportable java code in popular free software libraries and applications like OpenOffice.org, and people using features that are not implemented in free runtimes yet. Those are technical and educational problems, that can be solved with a little bit of good-will from all parties.

If the non-free java runtimes ever become free software, it will be because the alternatives becoming good enough to surpass them, not because of third parties begging the copyright holders to free them from the shackles of the restrictive licenses. There is no interest for Sun in a free software Java implementaion right now. If the alternatives start making inroads onto the server side, they may be inclined to reconsider their licensing scheme. Just like Trolltech did, when alternatives to Qt started becoming useable to create whole desktop environments, let alone applications. So if we want a free software Java platform, our best bet is not writing open letters to Sun, and begging them to donate code, but working on a better, freely licensed implementation instead. In the long run, "Le mieux est l'ennemi du bien". We can chose to attempt to reach the best, or to take what others assure us is good enough on their restrictive terms.

That aside, it would be great to see Sun and IBM take the plunge and turn their Java runtimes into free software today rather than tomorrow. But there is no business case in it for them, as far as the responses to the open letters go.

On the other side of the Java runtime world, free runtime developers collaborate between each other, and there is a lot of interest in better cooperation with the projects over the language fence (Mono, dotGNU, parrot). I believe that in a few years, the debate 'Java, C++ or C#' may look like an anachronism from the old days, when such questions were relevant, before free software implementations weren't superior to non-free ones. Just like the question 'Solaris, GNU/Linux or Windows' is gradually turning into a sure shot for GNU/Linux.

Kaffe 1.1.4 is out, finally. A lot of work on small bug fixes, and cleaning up the source code went into that, but nevertheless, there are still some challenges left for the new hackers, like fixing all the broken debian non-mainstream ports.

FOSDEM

Been there, seen it, it was great. I loved meeting all the great developers on different free runtimes, and even some first-generation kaffe hackers like DV. After seeing the energy there, how far we got with cooperation on GNU Classpath, and how much interest there is in even closer cooperation between different free runtime developers, I believe that the future belongs to free java runtimes.

It was like seeing the *BSD, Linux and Hurd people coming together to work out a way to produce an Ueber-UN*X.

My attempts to fix the bizarre 'function object code gets partially overwritten by garbage in middle of execution' bug on Cygwin, have turned up that the bug is even more bizarre than I thought originally. I thought I'd blame it on some bad array index in some C code. But the object code for the function gets partially overwritten before main is called at all. Now I am really, really puzzled.

Recentlog Threads

dwmw2: If you're sharing the repository on every single line you change, sure. But if you prefer to work locally with the copy in your own versioning system until your changes stabilize, then the RCS tags differ in not very meaningful ways.

I've never used -ko to import text sources, so feel free to call me a veggie ;) Isn't the effect that CVS treats the file as binary? I wouldn't want to have large, whole file diffs, on each checkin on the imported files if I'm tracking another project's progress in my CVS. But hey, I admit that I haven't read the Cederquist yet, so I may be completely wrong ;)

With the next developer release, 1.1.3 out of the door, the focus goes back to bug fixing, patching up platforms like m68k-netbsd, or cygwin, and improving support for Eclipse, as well as getting JBoss 3.2.x to run better.

Tomcat 5 is also on the list of apps, I'd like to see running well on the next release, due in 2 months.

Currently I'm fighting with a really bizarre crash on Cygwin : a function gets its first few bytes modified somehow. No idea why it happens, but the disassembly when I get the SIGSEGV is different from the disassembly before I run kaffe. Setting watches on the function didn't help.

The other bizarre problem is some broken assembler code on m68k, well hidden in a C macro. So now I'm slowly turning macros into inline functions and silently cursing whoever decided against using inline functions in the first place.

RCS tags are evil

RCS tags are those cute $Date, $Id, $Log etc tags you find in people's source code. The upside is that they are meant to give you easy access to versioning information. The downside is that they give you tons of bad diffs as soon as there is more than one person working on the project, or even worse, another project decides to import your sources.

RCS tags in CVS projects don't give you anything that the cvs command can't tell you on demand, without wasting space with redundant information in source files. RCS tags are so old fashioned, you better get rid of them today before someone looks at your code!

The GPL interpretation discussion that gets imposed on Kaffe developers every couple of months when someone notices that it's getting quite useable for things like running Eclipse has been won on debian-legal with a decisive 1:0 from debian-legalists in favor of a 'GPL doesn't propagate accross interpreter boundaries for VM-agnostic Java code' interpretation. I interpret the low volume of discussion as a 'no need to make a lot of fuss about obvious things' reaction of debain-legal members, who saved their breath to discuss the implications of the upcoming Apache Software Foundation licenses.

In a way, it's another sign that Debian is growing up from begging to please FSF to being an independant project, that doesn't take FSFs dogmas for granted. That and the GNU FSDL debate, of course.

Kaffe's getting fixed up for the next developer release, due next weekend. As usual, we have lots of high plans and hopes, but the progress that's been made in the last two months was quite huge. Eclipse 2.1 should run fine with kaffe out of the box now. Eclipse 3 M4 runs with a few patches from mjw, that will make their way into the release. Gjdoc support is on the way for the next release, so that we can finally have a good free Javadoc tool bundled into Kaffe. Better support for GNU Crypto has been intergrated, and improved support for JSSE through latest Jessie is being worked on, too. And, somewhat surprisingly for such an old free software project, one of the goals for this release is to have more docs. The idea behind that is of course to be able to use kaffe for the whole DocBook Java toolchain. We'll see how far we can get.

Of course, there is not enough time to put in everything we'd like to sqeeze in: the Mozilla plugin is dormant again, the Gtk AWT backend as well, and progres on GNU Classpath's AWT intergration is somewhat stalled again. Which is a sad thing, given that Stephane Messlin-Weber is looking forward to running his framebuffer AWT with a VNC backend on a free VM. It seems like everyone is writing AWT backends these days. ;)

And as usual, there are a few bugs that are very weird: Kaffe currently breaks on Fedora Core 1, and I'm having a hard time fixing it. It's also broken on sparc-*bsd, and I'd appreciate the help of developer familiar with sparc assembler to help out with that.

Finally, I spent a lot more time getting sidetracked on GNU Classpath and Mauve than I planned trying to get out patches submitted back into GNU Classpath. But for me it's very important to contribute back to the community of excellent free java runtime developers and help out as much as I can to liberate Java. And I am not able to find the perfect test suite that allows me to automatically split tests by API versions, automatically generate test data using reflection, etc.

One of the other things that got me sidetracked is the issue of computing dependencies for Java source files. It seems that there is no way to get that type of information generated and imported into a Makefile for use with Automake. Except from JavaDeps, the Lucent version, which is quite neat. It still is quite buggy, though, and doesn't have an option to split dependencies alongside source directories for inclusion into subordinate makefiles. That makes it slightly unuseable for kaffe, since the dependency file for the whole class library is about 5 MB and takes around 70 MB or memory to process with GNU make. Optimizing it sounds like a nice little project to hack on during the holidays.

Life

is O.K. in general, thanks for asking.