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.
Back to life, back to IRC. There is a preliminary #kaffe channel on irc.freenode.org.
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.