Older blog entries for robilad (starting at number 22)

Kaffe OpenVM

In the meantime, I got kaffe's Qt-based AWT implementation to work on qt-embedded out of the box. There were some build issues, and I finally had enough of the bug reports that I rebuilt my kernel with frame buffer support, and made the thing behave as it should. Next Qt-specific merge will be support for Qtopia. Jim Huang is leading the way there, and is working on an improved AWT implementation based on Qt.

Other than that, I'm picking up where I've left. Patches, bug reports, some coordination work.

The Freenet developers have been a pleasure to work with. They are regularly sending in useful bug reports, comments, and patches. Since Freenet uses a lot of threads, it helps to expose interesting bugs that don't show up in single threaded applications.

The Gzz developers have been active kaffe users as well, and exposed several glitches in the core VM. Tim Stack is doing some great bug fixing work there.

In other news, Svante Arvedal has contributed his IA-64 jit implementation to kaffe, so it would be nice to see someone merging it into the CVS tree. Chenghua Jia is working on the Windows CE port created by Rainer Keuchel, so hopefully that port will get merged in soon. Kevin D. Kissell is working on the MIPS jit, Jared Boone is going to do some work on the ARM jit, Tony Wyatt is currently fixing the AmigaOS port, and may do some work on the m68k and PowerPC jit. Helmer Krämer is documenting jit3 for Doxygen. Last but not least Vrihad Shoonya is working on getting the OJI plugin to function with latest kaffe and mozilla versions. I intend to do some more bug fixing work on the libraries.

Projects using kaffe

New releases all over the place: JanosVM 1.0 has been released. It's probably the first free software Java VM to feature an implementation of the Isolation API, coming into JDK 1.5, among other great work. On the other side of the Atlantic, Gilgul 1.0.7-2 has been released. Gilgul is an extension of Java which supports dynamic replacement of objects without the need to explicitly deal with existing references. So you can say a #= b , which means replace all references to a with references to b. A combination of Gilgul with BDBJ would yield a super-debugger: with bdbj you can find the bug, and step backwards, with Gilgul you can replace the buggy instance with a fixed one. I need to get the authors in touch with each other.

IRC

Back to life, back to IRC. There is a preliminary #kaffe channel on irc.freenode.org.

Bug Patterns

Ito Kazumitsu has come across an interesting bug pattern in kaffe's IO libraries : the problem is that some IO classes implement read() or read(char/byte[]) by delegating it directly to read(char/byte[], int, int) which can be reimplemented in a subclass to call read() or read(char/byte []), resulting in a circular sequence of calls blowing up the stack eventually.

In general, the problem can be summed up as: method M is implemented using virtual method N. Since there is no way to guarantee that in an extended class N won't be overwritten to utilize M, the safest way to implement M and N is to delegate their calls to a private/final worker method implementation N'.

In fact, Sun's JDK 1.4.1_01 suffers from the same class of problems. I've posted some example code on the kaffe mailing list that blows the stack of Sun's JVM by extending the LineNumberInputStream in an unfortunate way.

That is a rather interesting 'extensibility' problem for class library implementors, and for their users. I'd be interested to hear about tools that can analyse this type of problems.

Long time, no diary. I've got a few wicked weeks behind me, with very little work done on Kaffe OpenVM.

In short, my ex-girlfriend cheated me, and dumped me for a jerk from her workplace. So I lost interest in anything but self pity for a while. Now that rage has replaced that sorry feeling, I'm feeling much better. I went to an anti-war protest in front of the US Air Force base in Spangdahlen. That was fun.

Which brings me to the propaganda wars. It's not "members of nationality X" who are evil, but some specific individuals. The America-bashing on this side of the pond is not any better than Europe-bashing on the other. I'm sick of the "Ami go home" paroles, this planet is everybody's home.

That being said, I'm back at writing free software, so my next diary entries should focus on Kaffe again.

Kaffe OpenVM

It's been mostly cleanups, bug-fixing and documentation work. Lately I was busy with a lot of merges from JanosVM, who have released a 1.0 release in the mean time. JanosVM is probably the first publicly available Java VM that implements process separation (coming into Sun's JDK 1.5). And it's Free software.

The Cygwin woes continue. I tracked down the bug to some stack corruption issue in a jar handling function. I decided to 'ask someone who knows' and post a bug report to their mailing list. I went through Cygwin's bug reporting page, ran kaffe in Cygwin's (very crash prone) gdb, copied pages of gdb output to support my claim that it's a compiler bug, and waited.

Of course nothing happened. When after a week I somewhat trollishly asked if gcc2 was maintained at all under Cygwin, I got mildly flamed for assuming the bug is in the compiler and not in my code. The poster had apparently not bothered to look through my mail beside the 'I think this is a bug in gcc2 on i386-cygwin' and 'it works on i386-linux'. And I got told to install gcc2. The funny thing is that my original bug report, in order to conform to the Cygwin bug posting rules, had a longish attachment listing gcc2 as installed. And I was using gcc2 all the way, and stated that explicitly as well.

Lessons learned: when you try to get someone to look your way, and you're on a high volume mailing list, you should try to sound like a troll. Then you'll get some attention. If you follow the rules, noone will bother replying. Never submit all information on a bug at once, give it away pice by piece, to make it more interesting for your audience. That'll keep them hooked and motivated to solve your problem.

I'm not interested enough in getting kaffe to run on Cygwin to play attention grabbing games with busy Cygwin developers. I don't blame them: they are getting an enormous amount of mail every day. So did I, until I unsubscribed from the Cygwin mailing list today.

For me, it's interesting to compare how both Kaffe and Cygwin try to use the mailing lists as their bug database. It works somewhat for Kaffe, because the volume is rather small (a few hundred KB per month), so the issues get resolved rather quickly. But, as my Cygwin experience showed me, it's not a good substitute for a bug database when the volume goes up. Then you need some way to sepearate the trash talk from the more productive communication, i.e. a bug database.

Kaffe OpenVM

Sound works now out of the box, and compiles native libraries for whatever (i.e. ALSA, Esd) backends it finds automatically. So does the automatical java.math implementation picking: if GNU mp is found, then kaffe uses its own native implementation. If no GNU mp is found, it now uses a pure java implementation from GNU Classpath. That's good news for Jython. Now I need to fix the remaining bugs Kaffe shows with their installer, and we're set.

Kaffe now interprets -classpath like JDK 1.2 and above, adding the parameter to the bootstrap classpath. Someone should write a -bootstrap option to set the bootstrap classpath as well, but its use is rather limited.

Dmalloc support is also working now. So I could spend some time debugging the memory management. Except that I can hardly find any bugs in kaffe, but I find memory errors for some stuff in libc ...

ia64-linux works again. I dropped a change to configure.in when I merged it in, and noone noticed until recently. There are still some bugs with this one, about a quarter of the regression tests fail.

Kaffe got support for user defined clas library profiles. Now you can tailor-suit the Java class libraries to the needs of your application. Don't need JAXP or RMI for your embedded Java app? Just edit an ASCII class library profile file to leave it out and watch your rt.jar shrink.

There was also some work on the build system, and we're getting closer to being able to run 'make distcheck' again. Seems like I've been hacking and breaking the build system for too long if I can get excited about that. Hero of the week for putting a lot of work into improving the build system and catching my mistakes almost before they happen is Tim Stack.

Cygwin remains subtly broken, but given that the KaffeCE README files talk about brokenness of ZipFile access (and implemented fixes), I'll check that out for ideas. Windows CE is close enough to Cygwin that it might work ;)

Transatlanic Strong Talk Championship

It is like wrestling. We all know it's all show, and the blows don't really happen, but it looks very spectacular on TV.

By the way, Michael Moore's 'Stupid White Men' is selling like sliced bread in Germany. If "I'm Afraid Of Americans" was re-re-released, it would probably get quite high in the charts here in '.de'.

I personally prefer Atari Teenage Riot, though. But they'll never get into charts. It's music for cleaning spaces from people. When I saw them play on Big Day Out three years ago, it went like this: they came on stage, shouted something about revolution, and then produced a massive wall of electronic noise and screams for about an hour. Almost everybody went away to do whatever one does when a crappy band occupies the stage. I stayed, and enjoyed them very much, though.

Yugoslavia

is now officialy gone.

I wonder if the "Commonwealth of Serbia and Montenegro" (I'm not sure what the real translation is) will get a new top level domain, or if they'll keep .yu for a while, or if they'll get two top level domains, one for Serbia, the other for Montenegro.

Death

My grandfather died two weeks ago. I've lived 12 years with him and my grandmother, who died in 2000. He was an awesome man. Fought the Nazis, raised four kids, and stayed agile and focused into high age. He fell and cracked his skull around new year, and never really recovered, despite being hospitalized for about two weeks. He died peacefully at home, with his kids around him, fully aware what's happening. I think that's a nice way to pass away.

Kaffe OpenVM

I reworked the sound configuration process, to automatically discover the installed sound backends and compile tritonus libraries accordingly. Of course that broke the build on just about any other other machine than mine. This should be fixed now.

The Freenet and Jython installer assertion bug is fixed, only to be replaced by some new assertions on OpenBSD when running Freenet. This time it seems to be something about file I/O and threading. I'll have to put OpenBSD on my test machine and start digging around what might be causing this.

The Jython installer still crashes in fascinating ways, too. At the end of the installation, it tries to (de)serialize some really complex object. As kaffe's serialization code uses recursion to traverse the object tree, Jython's installer blows the stack after a while. I've got a good idea on how to avoid recursion here, but I'll have to dig into serialization first before I can figure out how to implement it properly.

I received two new bug reports about kaffe's BigInteger implementation not working. It's using GNU MP, so it doesn't work when the library is not present, and you get errors about missing methods, intializers and what not. As not everyone can be expected to have cryptographic ammunition libraries on their systems, I've proposed to also have the pure java implementation from GNU Classpath as a configure time choice. It'll come into kaffe over the course of this week, when I find some time to merge it in.

My first patch for ant was applied yesterday. Now the latest ant version in the CVS works again with kaffe. So will the upcoming 1.5.2 release.

I've tested the GNU Crypto 1.1 prereleases, and that of course turned up a few new bugs in kaffe. The good thing about working on a free software java implementation is that you can never get bored ;)

I've also tried to teach kaffe's configure.in to build kaffe --with-dmalloc, but that didn't really work out so far. It gets compiled and runs all right, but I don't get any output from dmalloc. Suspicious.

Finally, more sensible --classpath option support is coming into kaffe. Since jdk 1.2, --classpath only adds classes to the core system classes, and doesn't replace them. A lot of shell scripts for running java software assume that, which makes it rather painful to run such software on kaffe, as you'd have to add the location of kaffe's rt.jar to --classpath, too. Well, no more. I've posted a patch on the mailing list to fix that.

Kaffe OpenVM

Jython 2.1 now runs on kaffe. Gzz now runs on kaffe. BCEL's verifier now runs on kaffe (again). It feels good when bricks start falling into place.

I've found a nice test case for an old assertion bug that has been troubling Freenet users on kaffe for a while. Unfortunately, it was somewhat hard to reproduce, as it took days to show up. On the other hand, you can just run the Jython 2.1 installer with current kaffe's sources and it falls flat on its face almost instantly. Hopefully this will lead to someone figuring out what's wrong faster.

But when you install Jython using Sun's JDK, it works quite nicely in kaffe. Nicely enough for Gzz, at least. I'd like to see the mail client Columba, written in jython, run on kaffe, too.

On a lighter note, someone crashed into the kaffe mailing list saying that kaffe was obsolete, and developing it a big waste of time. Instead, he proposed to fold kaffe into Mono. Much fun was had on all sides. Then the guy changed his mind and wanted to write a SWING replacement using GTK. I'm wondering what he'll come up with next. Ah, the joys of playful, energetic youth, when writing a kernel seems possible over the course of a single weekend ;)

Kaffe OpenVM

The Cygwin annoyances continued. I've reinstalled Cygwin from scratch on my notebook. Trying to debug kaffe in gdb regularly sends it into core-dump-land. The workaround to use the java.util.zip implementation from GNU Classpath works, and I'd like to check it in, but the pure java zip file deflator delays program startup by a few seconds (minutes in interpreter mode). I'll have to wait until Cygwin gets a more useful gdb and debug the native code, since it would be quite pointless for embedded users to have pure java implementation of java.util.zip that takes ages to load classes. On the other hand, I have some hope that Artur Besiadlowski can improve the performance of the pure java implementation a bit further. He's done a lot of work on it recently for GNU Classpath.

On the bright side, I've just merged in javax.sound from tritonus into kaffe's CVS tree. Sampled sound is available via the ALSA and Esd backends. MIDI should work through ALSA, but there seems to be some obscure bug that prevents me from playing mid files.

My hero of the week is Dylan Schell, who ported kaffe to Playstation 2 running Linux. Close second is Helmer Kraemer, who provided some patches to kaffe's javah tool that made it possible to merge in javax.sound.

If I should pick a hero of the month, it would be the Tritonus developers, who have been very helpful during the merge. They actually changed their backend libraries from C++ to C after I complained that C++ libraries are quite painful to support under libtool. Matthias Pfisterer did an amazing load of work to get tritonus into kaffe.

In the patch queue we have a submisson that ports kaffe's Qt based AWT backend to Trolltech's Qtopia desktop. That should let kaffe run on the Sharp Zaurus with AWT.

My Kaffe-On-MingW adventures have resulted in some small patches, but I haven't succeeded in getting it to compile, let alone run. I don't undertand enough about native win32 threading and kaffe's own threading mechanisms to be able to get it to work. Volunteers are welcome to take off where I left.

More stuff has been merged in from GNU Classpath, most prominently java.awt.Graphics2D and the java.awt.image.renderable package. I'll focus on finding bugs in kaffe's and Classpath's collections implementation next, so I could eventually drop the GNU Classpath collections over kaffe's existing implementation. While kaffe's Collections work quite well, they don't provide SubMaps, and japitools won't run without them.

9 Dec 2002 (updated 9 Dec 2002 at 15:21 UTC) »
Kaffe OpenVM

The jaxp bug has been fixed. I have to remerge with GNU JAXP to get the bug out of kaffe's sources as well. So the hero of the week was Ito Kasumitsu, who helped considerably to get that one pinned down, providing test examples, doing regression testing, and finding the last glitch that made a the latest patch fail. It feels very good to have such commited people on board.

The swab prototype mess has been mostly fixed by Pat Tullmann. Looks like FreeBSD has swab defined in <strings.h>. Linux is a whole different story: a swab declaration is provided in <unistd.h> but gcc can't find it. g++ on the other hand, has no problem finding it. I'll file a bug report to the GNU libc, and see who's the blame for the mess there.

I have looked at the Cygwin problems. Apparently the bug is somewhere in kaffe's native code for the java.util.zip implementation. As Classpath has a pure Java implementation of java.util.zip, I'll try using that instead. So you might see more of GNU Classpath code coming into kaffe soon.

Finally, I've spent most of the time last week trying to get real javax.sound support into kaffe using tritonus. I've got it to work, but it's not ready for checkin yet. Libtool 1.4.3 has problems generating shared libraries from C++, so I have to upgrade to libtool from CVS, and that one means I have to update our autobuild scripts for automake 1.7.1 and autoconf 2.56. It is a rather painful excercise, as latest auto* tools are more sensitive to garbage in our build scripts than the older releases, without giving warnings. On the other hand, this upgrade might benefit the Cygwin platform, too, squashing the "you need to run configure twice" bug. I'll turn to Cygwin once I have javax.sound working.

I've also looked at JacORB recently. It seems to be the latest big missing piece in the picture (except javax.swing, and javax.imageio, javax.print), that kaffe's class library lacks, for which there is a free software implementation. It would be nice to have that code merged into kaffe as well.

Kaffe OpenVM

I didn't get much done this time. I tracked down something that looks like a bug in our jaxp sources. Bug report and a triaging fix are on GNU JAXP mailing list.

In other news, I managed to break the nightly builds with a change of a prototype for swab. I need to figure out why configure doesn't pick up the declaration from the headers.

The Cygwin problems persist. GNU gdb crashed under Cygwin a couple of times while trying to debug the problem, so it was not really useful. Now I'm reverting to the old and tried method of using kaffe's own debugging facility -vmdebug. And I've compiled kaffe in interpreter mode, so I can trace each bytecode as it gets executed. That should be enough to trace the bug to its origin. When in doubt, log everything.

My MingW porting adventures are postponed, as I had to reinstall Windows on my notebook. I took the chance to put Qnx 6.2 on it as well, so I might get a chance to fix the Qnx port one day.

tromey,Uraeus,db

I think one of the main reasons why there is apparently more interest in Mono than in gcj is Miguel. He's been doing a lot of work to promote the project. And he is a really funny guy. On a mission. The strong oppposition he was facing in the initial stage helped get the Mono name out to people.

On the other hand, free java implementations suffer from a lack of good publicity anyway. Most java developers are developing on/for Sun's implementation, and are able to use it on their platforms for free. Most people developing for Sun's platform means that a lot of java code out there is not really portable accross implementations. It often depends on some "misfeatures" of Sun's implementation, or on parts for which no free implementations exist, like Swing.

That situation casts a bad light on free implementations. Just search google groups for kaffe and LimeWire to see what I mean. Most java on linux FAQs recommend going with Sun's implementation, and deinstalling whatever free implementation is there. That's a hurdle Mono doesn't have to face in order to attract attention.

The second part is even more important: there is already a good enough "free as in beer" implementation for most people, provided by Sun. Microsoft's .NET tools won't work on Linux as far as I know, so Mono doesn't have to fight against good, free beer competition on that platform. With Java, the situation is very different: Sun's and IBM's JVM are quite good, their class libraries implement the whole API, and they work on most linux distributions, as well as some BSDs, as far as I know.

It is a much tougher market for eyeballs gcj and other free java implementations are in, compared to Mono. I think that will start to change in a couple of years when/if free implementations start to prove superior to non-free ones. I believe that's going to happen one day, just like gcc is now the compiler of choice for a lot of platforms. It takes a lot of effort to get there, though, and gcj, kaffe, classpath etc. need a lot of help.

Kaffe OpenVM

The Qt based AWT backend has been backported to work on Qt2. I've received a patch doing that, but unfortunately, it didn't really work. It was not so hard in the end to get it right. I just had to fight with my SuSE 7.3 installation that tried to compile against Qt1 and gloriously failed after the moc step. Is anyone still using Qt1 out there? I don't think it's worth backporting to Qt 1, really. Suporting Qt 2 has some justification, as Trolltech released a free as in beer version for free software developers for Win32. That could give kaffe another functioning AWT on win32, if the win32 native API based one is functioning at all. I can't say, as I still have to fix an ugly Cygwin bug.

I've updated the files comping from GNU libtool to libtool version 1.4.3. Why can't libtoolize just copy libtool.m4 along with the other files? Kaffe used to have the libtool macros in its acinclude.m4, so a simple libtoolize resulted in a setup that was very broken: new libtool files, old libtool.m4 autoconf macros, huge chaos. Only after deleting acinclude.m4 I was able to get a working setup again. Oh yes, and copying libtool.m4 from the source archive, as it was nowhere to be found in /usr/share/libtool .

More packages from GNU Classpath have found their way into kaffe's class library, mostly javax.* stuff. And this time around, I've also included the most of GNU jaxp, giving kaffe good XML support. Since today, kaffe comes with a built-in XML parser, Aelfred2, taken from GNU jaxp.

My URI patch made Saxon 7.3 work with kaffe. It will probably go into GNU Classpath, now that I've started the GNU paperwork voodoo with tromey. I went ahead and checked it into kaffe's CVS, as it will take some time for the paperwork to be done, I guess.

I've also tried to compile a few typical XML related packages beside Saxon 7.3. Ant 1.5.1 builds with some patching. The main problem is that the Ant developers have a hard reference to sun.something.Base64 in their code, a class that doesn't exist in kaffe, and probably never will. Luckily, ant comes with its own Base64 encoder, so with a little use of reflection this works out o.k. I'll submit a patch to the ant developers, hoping that this one gets accepted.

Latest releases of xp, xt, crimson, xalan, jdom, logkit and avalon all build nicely on kaffe now. Use -Dbuild.compiler=kjc to tell ant to use kjc as its compiler. One might need to add some jars to CLASSPATH if ant complains about not finding classes, but overall, it just builds. That's a big leap from about a year ago. I should benchmark kaffe using xsltmark again.

Among interesting things that don't build yet are xerces, fop and batik. So while I could generate html documentation for kaffe from a kaffe.xml DocBook document, due to fop 0.20.4 not working on kaffe yet, I can't get PDF docs. Is there a pure Java solution to generate man pages from DocBook? Or, in other words, are there XSL stylesheets that generate man pages from DocBook documents?

I've put MingW on the windows partition of my notebook. I'd like to give cccl wrapper for Microsoft Visual C++ a try. That would in theory enable me to build kaffe on win32 using automake and MingW instead of fiddling with MSVC++ project files. And last but not least, there is a port to MingW in the pocketlinux kaffe tree that could be merged in, while I'm on that platform.

13 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!