[kaffe] Re: kaffe 1.1.9 plans

[Dalibor Topic]

Riccardo wrote:
> Hi,
> 
> On Sat, 22 Sep 2007 21:59:40 +0200, Dalibor Topic <robilad at kaffe.org>
> wrote:
> 
>> Hi all,
>>
>> We've got the migration classpath 0.95 ahead. I'd like to take that
>> opportunity to switch to using the system installation of gnu classpath,
>> and remove the source code for it from Kaffe, slimming down our tarball
>> & configure times.
> 
> From what we discussed on the Mailing list this seems to be lethal for
> builds on machines without a java 1.5 compiler on it, since jikes is gone.

There are Eclipse's ecj & OpenJDK's javac, and one should be able to use
pre-built jar files once the switch happens.

>> I'd love to see the skyos port merged in for the next release.
> I'd love PPC jit :) (Hey, Guilhem, reading me? When you have time tell me)

Cool, keep the patches coming.

>> There are few other things I'm thinking of, like looking at the gcj
>> bindings again, and checking if we could switch over to use boehm-gc as
>> the default gc on the platforms that support it, as well as switching
>> over to classpath's javah and removing kaffeh, and starting to use glib
>> for data structures, portability wrappers, and all the fun stuff that's
>> currently clogging our configure script.
> 
> NO, NO GLIB, PLEASE. Not another damn dependency and I'm allergic to
> glib anyway. Really, no use.

I'd like to gradually start using glib for a couple of things:

* debug logging (alternative would be GNU nana)
* command line option parsing (our manual code in main.c is rather ugly)
* data structures (no need to have our own hashtable, lists, etc.)
* fixed size types (without requiring c99, allowing to simplify gtypes,
etc.)
* atomic functions (which we're now copying and pasting from gnu libc,
and Guilhem is no longer around to maintain them)
* string & utf8 utility functions (allowing us to throw away the
implementation in kaffe)
* timers & counters (making the stats module leaner)
* and various little portability/utility functions that we otherwise
have to maintain ourselves, which is something I'm not a huge fan of.

In addition, I think it would be nice in the long run (say, 1.1.10) to
replace kaffe's own class file parsing stuff with something like
http://jclassinfo.sourceforge.net/ as that would allow us to strip out a
lot of jar, class path & class file handling code from the VM core.

The simpler the core becomes by using external libraries for common
tasks, the easier it should be to maintain in the future with the
handful of active developers around, and have more regular releases.

>> The next release is tentatively scheduled for November 4th.
> 
> 2008? :)

2007, of course! ;)

cheers,
dalibor topic