Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Dalibor Topic wrote: Kiyo Inaba wrote: D] Merge in the dropped cygwin patch Still todo. I've made some progress on this, in that I've made the current GNU Classpath head build on Cygwin (patches mostly applied upstream). Now I'm making kaffe build with that, before I investigate the patch. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe + classpath 0.95 (Was: Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe))
Mark Wielaard wrote: Hi Dalibor, On Wed, 2007-06-13 at 23:49 +0200, Dalibor Topic wrote: Unfortuntely, there is one VM Interface change that (I assume) makes it hard to support both 0.93 and 0.95 (VMTimezone), so I think we should stay with 0.93 for the 1.1.8 release, and kick out a 1.1.9 soon afterwards. Meanwhile, it wouldn't hurt to get Kaffe added to builder.classpath.org, now that it supports the 'separate classpath' feature that JamVM Cacao support. Mark, can you take care of that? Very cool! Yes, I can take care of that, but it will take a couple of days, so ping me again next week if it isn't done yet. Ping. :) cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe + classpath 0.95 (Was: Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe))
Hi Dalibor, On Wed, 2007-06-13 at 23:49 +0200, Dalibor Topic wrote: Unfortuntely, there is one VM Interface change that (I assume) makes it hard to support both 0.93 and 0.95 (VMTimezone), so I think we should stay with 0.93 for the 1.1.8 release, and kick out a 1.1.9 soon afterwards. Meanwhile, it wouldn't hurt to get Kaffe added to builder.classpath.org, now that it supports the 'separate classpath' feature that JamVM Cacao support. Mark, can you take care of that? Very cool! Yes, I can take care of that, but it will take a couple of days, so ping me again next week if it isn't done yet. Or you could look at the builder scripts in CVS yourself: http://sources.redhat.com/cgi-bin/cvsweb.cgi/builder/scripts/?cvsroot=mauve Cheers, Mark signature.asc Description: This is a digitally signed message part ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe + classpath 0.95 (Was: Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe))
Dalibor Topic wrote: Dalibor Topic wrote: This seems to work a bit better than I expected. I've just built Classpath 0.95 separately, and then built Kaffe using it [1], and, other than three failing regression tests (nothing really serious, just small changes in expected test output), it works, and I can see the WidgetsDemo, too, so I guess Swing/AWT works that way, too. The two failing regression tests with 0.93 are fixed in 0.95, as per Ito's patches. I've cleaned up the failing tests, so that they work now with both the classpath version in kaffe, and with classpath 0.95, so that all tests pass with 0.95 (and we have two XFAILS). cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Dalibor Topic wrote: Looking at a gcc checkout, I see that the m68k gcc has a builtin define for coldfire, __mcoldfire__, couldn't we use that? (The builtin_define is in gcc/gcc/config/m68k/m68k.h) I've discussed that off-list with Roland (== tbfg on IRC), and according to his tests, gcc predefines __mcoldfire__ for coldfire CPUs, so I think we could use it to #ifdef / #ifndef parts of the JIT for coldfire. Alternatively, we could add a configure switch. I'd prefer not having another configure option, though, it it's something we can autodetect. The configure script is awfully long enough as it is. :) cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
kaffe + classpath 0.95 (Was: Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe))
Dalibor Topic wrote: Dalibor Topic wrote: Dalibor Topic wrote: D] Remove the merged in GNU Classpath and just use an existing installation I did the lower-half separation (separate build) but not yet change the upper-half to point the location of classpath. Ideas like 'with-classpath-prefix', 'with-classpath-libdir' or 'with-classpath-includedir' involved in Cacao should be needed. I've got a local version of that building, using a slightly adapted classpath.m4 from Cacao and a local install of classpath. I'm working on making the regression tests build work with classpath 0.93 (closest to the version in our tree). Wprks now locally, as well, with two failing regression tests left over to look at. Commit coming as soon as they are fixed. It turned out that the two failing regressions have been fixed by Ito after my merge of GNU Classpath 0.93 into Kaffe in our copy of classpath, so I'll check in what I have. This seems to work a bit better than I expected. I've just built Classpath 0.95 separately, and then built Kaffe using it [1], and, other than three failing regression tests (nothing really serious, just small changes in expected test output), it works, and I can see the WidgetsDemo, too, so I guess Swing/AWT works that way, too. The two failing regression tests with 0.93 are fixed in 0.95, as per Ito's patches. Unfortuntely, there is one VM Interface change that (I assume) makes it hard to support both 0.93 and 0.95 (VMTimezone), so I think we should stay with 0.93 for the 1.1.8 release, and kick out a 1.1.9 soon afterwards. Meanwhile, it wouldn't hurt to get Kaffe added to builder.classpath.org, now that it supports the 'separate classpath' feature that JamVM Cacao support. Mark, can you take care of that? cheers, dalibor topic [1] ../kaffe/configure --prefix=/tmp/kaffe-cvs-with-classpath --with-system-classpath --with-classpath-prefix=/tmp/classpath-0.95/ --with-ecj make make check ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Dalibor Topic wrote: Dalibor Topic wrote: D] Remove the merged in GNU Classpath and just use an existing installation I did the lower-half separation (separate build) but not yet change the upper-half to point the location of classpath. Ideas like 'with-classpath-prefix', 'with-classpath-libdir' or 'with-classpath-includedir' involved in Cacao should be needed. I've got a local version of that building, using a slightly adapted classpath.m4 from Cacao and a local install of classpath. I'm working on making the regression tests build work with classpath 0.93 (closest to the version in our tree). Wprks now locally, as well, with two failing regression tests left over to look at. Commit coming as soon as they are fixed. It turned out that the two failing regressions have been fixed by Ito after my merge of GNU Classpath 0.93 into Kaffe in our copy of classpath, so I'll check in what I have. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Kiyo Inaba wrote: Dalibor and others, Dalibor wrote: D) Merge in tbfg's m68k patch. Kiyo, could you take a look at it? http://www.kaffe.org/pipermail/kaffe/2007-June/104949.html Yes, I've spent some time to investigate this proposal. In general, the patch posted tries to comment out some instructions which are not supportded by coldfire, and no simple way to co-exist this port with m68020/030/040 ports. I think we may have to introduce one configure option to force the make for coldfire or not. Thank you, Kiyo. Looking at a gcc checkout, I see that the m68k gcc has a builtin define for coldfire, __mcoldfire__, couldn't we use that? (The builtin_define is in gcc/gcc/config/m68k/m68k.h) Anyway, by this weekend, I may be able to post my proposal to merge this port. Great! By the way, I am still playing with arm-jit3, and got some big progress. Cool, then I'll defer playing with arm-jit3 until you're ready for check in, and continue working off the other tasks from the list. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Kiyo Inaba wrote: So, from releasing point of view (based on Dalibor's and Riccardo's wish list), we still have to D] Either fix the serialization bugs leading to the two failing regression tests, or mark them as XFAILs, and file bugs for it in GNU Classpath's tracker, adding the failing tests to Mauve The XFAIL part is now done. D] Merge in the dropped arm jit patch Merged by Dalibor, but verified not working by Kiyo. I'm currently waiting to finish making kaffe build with a classpath install first, as building glibj.zip in the emulator takes too long. D] Merge in the dropped cygwin patch Still todo. D] Merge in the interix port Still todo. D] Remove the merged in fastjar and zlib and just use the jar tool on the system Done. D] Remove the merged in GNU Classpath and just use an existing installation I did the lower-half separation (separate build) but not yet change the upper-half to point the location of classpath. Ideas like 'with-classpath-prefix', 'with-classpath-libdir' or 'with-classpath-includedir' involved in Cacao should be needed. I've got a local version of that building, using a slightly adapted classpath.m4 from Cacao and a local install of classpath. I'm working on making the regression tests build work with classpath 0.93 (closest to the version in our tree). R] fix it at best of classpath so that swing/gtk peer runs That could work out of the box with the locally installed Classpath, once the previous part is done. I'll also merge in the stack of build system patches that went into Classpath after 0.95 to make it work with automake 1.10. D) Merge in tbfg's m68k patch. Kiyo, could you take a look at it? http://www.kaffe.org/pipermail/kaffe/2007-June/104949.html cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Dalibor Topic wrote: D] Remove the merged in GNU Classpath and just use an existing installation I did the lower-half separation (separate build) but not yet change the upper-half to point the location of classpath. Ideas like 'with-classpath-prefix', 'with-classpath-libdir' or 'with-classpath-includedir' involved in Cacao should be needed. I've got a local version of that building, using a slightly adapted classpath.m4 from Cacao and a local install of classpath. I'm working on making the regression tests build work with classpath 0.93 (closest to the version in our tree). Wprks now locally, as well, with two failing regression tests left over to look at. Commit coming as soon as they are fixed. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Dalibor and others, Dalibor wrote: D) Merge in tbfg's m68k patch. Kiyo, could you take a look at it? http://www.kaffe.org/pipermail/kaffe/2007-June/104949.html Yes, I've spent some time to investigate this proposal. In general, the patch posted tries to comment out some instructions which are not supportded by coldfire, and no simple way to co-exist this port with m68020/030/040 ports. I think we may have to introduce one configure option to force the make for coldfire or not. Anyway, by this weekend, I may be able to post my proposal to merge this port. By the way, I am still playing with arm-jit3, and got some big progress. But this indicates mips-jit3 should not work right now. Are there anyone who can make mips-jit3 work for the CVS-head? Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Future directions for Kaffe
Hi everybody,
Hi Jim and everybody,
Thanks Jim to keep kaffe.org up and running.
So I'm assuming that the project isn't dead, it's just somewhat dormant.
It's been somewhat dead/dormant throughout much of it's history, but
it's still here, isn't it? :-)
Yes, it's still here! As I posted previously, there should be some
guys still trying to make it better.
* I'm embarrassed to admit that I don't even have Kaffe running on my
new MacBook under OS X. I got it to compile, but I couldn't get it to
even run Hello World. If I spent some time on it, I imagine I could
figure it out. I just haven't spent the time. I hope it still runs OK
on Linux, but I haven't tried that recently either.
According to the weekly regression test I do, kaffe still works with
(in my environment) for {ia32,m68k}*{linux,netbsd} and sh3*linux. Of
course even the small test suites kaffe provides some errors are
reported and it's good new to me that there are still enough chance
to play with ;-)
* I think Kaffe probably is still the simplest full JVM implementation
that isn't just an interpreter. It's been used for all manner of exotic
porting projects that might just be too hard to do using something like
OpenJDK or gcj.
This is the major reason why I still continue to play with kaffe. I
know that kaffe's jit (or jit3) is not at the same level as the state
of art just in time compiler technique, but still it is ok to support
'non major CPU architecture' like mc68030.
* If anybody is currently doing something interesting with Kaffe, or has
any aspirations for it, please send some email to the list! We need the
ideas and the traffic!
Except for the fixing funny configure trouble introduced to m68k-netbsd
(core dump while configuring), I still try to squeeze my time to make
kaffe work (again) for mc68000 (or coldfire, in these days) or sh3 with
its jit3. I am not sure whether it can be said an 'interesting' project.
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Future directions for Kaffe
Jim Pick wrote: Hi everybody, Hi Jim! It's been a quiet month on the mailing list so far. That's partly my fault, I think, since the mailing list was broken for some time. Thank you for fixing it again. It looks like the last CVS commit was 5 weeks ago. I see Dalibor went to FOSDEM, and did some talking about Kaffe there. Yes, there is a small write up on http://robilad.livejournal.com/8458.html . So I'm assuming that the project isn't dead, it's just somewhat dormant. It's been somewhat dead/dormant throughout much of it's history, but it's still here, isn't it? :-) Indeed :) And clearly, all the free Java runtimes and Classpath are in a state of transition, as we wait for Sun to release the rest of OpenJDK. I'd like to liven up the list a bit, and maybe start a bit of discussion on where Kaffe should go next. Here are some things I'd like to talk about: * I definitely need to do some work on upgrading the server, and fixing up the website. Currently it's running a really old version of Debian, so it needs to be upgraded. I'm just scared of all the breakage that will happen. I'm slowly building up my hosting capabilities, but it's just a hobby, and I have real life things going on, so I move at a glacial pace. If anybody wants to help out with any of that, I'd really appreciate it. I happy to keep hosting it indefinitely. * I think a wiki running on top of Kaffe would be really nice. :-) * On the other hand, there are establishing free software hosting platforms like Sourceforge, Savannah, Google Code, etc. that might work better than just running everything on our own server. Our current infrastructure is pretty much still using technology from the 1990s. We don't even have a blog or a wiki, or any continuous integration or distributed version control. I'm open to migrating things if that's what people would prefer. You've done a great job keeping the infrastructure together and alive. Thank you for all the good work on keeping the playground in a good shape, Jim, and for providing the place for us to play in. As far as migrating things goes, I think that mostly depends on how much additional infrastructure work one could realistically expect to be done by volunteers. I'm rather sceptical about that, since infrastrucural work is not really sexy for new developers. The 'the web site could be improved by doing x,y,z' feedback I received quite often over the past years has very rarely been followed up by actual patches, or someone volunteering to revamp the site. In that light, I'd recommend 'outsourcing' additional services to external infrastructure providers, i.e java.net, Google Code, etc. simply because it removes the future maintenance burden from the equation. * Technically speaking, I'm still the project leader, by virtue of rescuing it from the ashes of Transvirtual. But Dalibor is really the guy who has been doing most of the work. I'm not really doing much with Kaffe personally, so if anybody else wants to step up and be a real project leader, feel free to volunteer. I'm still happy to keep hosting the project and helping out with the releases. I don't use Kaffe (or Java, for that matter) for my personal work (SPASS is written in C C++, and my area of research has nothing at all to do with JVMs), so my own priorities would be quite different from someone using Kaffe for their personal work, I'm afraid. In the past five years I've used Kaffe as a playground for ideas for acceleration of the liberation of the Java platform, as well as to learn about new tools, and make new connections. I think it has worked out great as a soapbox, allowing me to formulate ideas and bring them into the mainstream of the regular Java audience, thanks to Kaffe being a strong 'brand', while at the same time pushing the envelope of what we can tie together under the umbrella of a 'free software SDK for the Java programming language', and allowing distributors to use it as a runtime until gcj took over that role. So, as a 'political platform', Kaffe has been incredibly successful, I think, as what started out as waking up a dormant project back in early 2002, ended up being one of the projects that crucially pushed the boundaries on what was thought to be possible for free software JVMs, and bulldozing a path forward until things started to get a lot better in the Java world. Part of the strategy going from late 2002 on was to avoid the problems of the 90s, where Kaffe's parent company and gcj's parent company were engaged in a fruitless effort to compete with each other in the embedded space, leading to a lot of friction with little to show for it. So there was no point in trying to re-launch Kaffe as a contenter for the 'crown' of the free JVMs, as that would have just led to friction over the scarce volunteer developer resources, rather than 'lifting all boats'. GNU Classpath turned out to be the project that was
kaffe 1.1.8 (Was: Re: [kaffe] Future directions for Kaffe)
Tim Bevan wrote: Jim Pick wrote: Dalibor has been doing a great job. * Speaking of releases, we really should do another release sometime. Yes please. I would like a stable version containing the fixes I needed. Thanks! Here is what needs to be done for 1.1.8: * Either fix the serialization bugs leading to the two failing regression tests, or mark them as XFAILs, and file bugs for it in GNU Classpath's tracker, adding the failing tests to Mauve * Merge in the dropped arm jit patch * Merge in the dropped cygwin patch * Merge in the interix port * Remove the merged in fastjar and zlib and just use the jar tool on the system Potentially: * Remove the merged in GNU Classpath and just use an existing installation Volunteers, step ahead! cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Future directions for Kaffe
Jim Pick wrote: Hi everybody, * I imagine that in the future, people will most likely look to OpenJDK as a starting point to add their enhancements. Is there still a role for Kaffe to play here? As a free open alternative probably. It may be that it has had it's day and OpenJDK will take over. I would not rush to bin it and I would not rush to alter it too much. Too much change simply introduces instability - people will find other JVMs that simply work Someone needs to come up with a new charter for the project what is it that Kaffe supplies that OpenJDK cannot? It may take some time to discover what this really is. * I think Kaffe probably is still the simplest full JVM implementation that isn't just an interpreter. It's been used for all manner of exotic porting projects that might just be too hard to do using something like OpenJDK or gcj. Which is a reason to keep it simple and easy to port. * Kaffe is licensed under the GPLv2. So is OpenJDK. But Kaffe doesn't require copyright assignment, and we're pretty open. Sun doesn't have to vette the code going into Kaffe. That suggests that perhaps we could merge in large parts of OpenJDK, and provide a place for people to do really experimental stuff that Sun isn't going to permit in their version. Is this something we should consider? I would say stay clear of getting too close to OpenJDK - if there is little difference between the two projects, it is Kaffe that is pointless. * In other words, should we go big? And merge in as much stuff as possible. That could be problematic, since Kaffe is already pretty huge. Maybe we could adopt more of a distribution approach, and break things into a bunch of modules that are all developed to work together? Stability with quiet growth would probably keep Debian on board better. * I think we've been trending towards the go big direction for some time, with all the Classpath merging and other projects, and the core has been somewhat neglected. It's been really good to support Classpath this way, and it's helped to get a lot of Java stuff integrated into Debian. On the other hand, I think the build itself is just too intimidating. It's massive. I think most prospective developers would probably give up before getting it to build the first time. Our configure scripts are almost an operating system in and of themselves. :-) Classpath is a bit special? You want a Java 1.X on top of Kaffe and Classpath appears to be the way to get that - or support the equivalent in OpenJDK. -- Tim Bevan Principal Software Engineer +44 (0)1223 420 414 1Spatial Limited Registered in England No. 4858580, VAT Reg. No. GB 896685149 Registered Office: Cavendish House, 6 Cambridge Business Park, Cambridge, CB4 0WZ, UK ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Future directions for Kaffe
Jim Pick wrote: Hi everybody, It's been a quiet month on the mailing list so far. That's partly my fault, I think, since the mailing list was broken for some time. It looks like the last CVS commit was 5 weeks ago. I see Dalibor went to FOSDEM, and did some talking about Kaffe there. So I'm assuming that the project isn't dead, it's just somewhat dormant. It's been somewhat dead/dormant throughout much of it's history, but it's still here, isn't it? :-) And clearly, all the free Java runtimes and Classpath are in a state of transition, as we wait for Sun to release the rest of OpenJDK. I'd like to liven up the list a bit, and maybe start a bit of discussion on where Kaffe should go next. Here are some things I'd like to talk about: * Technically speaking, I'm still the project leader, by virtue of rescuing it from the ashes of Transvirtual. But Dalibor is really the guy who has been doing most of the work. I'm not really doing much with Kaffe personally, so if anybody else wants to step up and be a real project leader, feel free to volunteer. I'm still happy to keep hosting the project and helping out with the releases. Dalibor has been doing a great job. * Speaking of releases, we really should do another release sometime. Yes please. I would like a stable version containing the fixes I needed. * I also haven't been responding to emails asking me for help getting Kaffe to run. I'd like to, but since I don't even have it working for myself, I'm not really in a position to help out. I get so much spam nowadays that I hardly even use email anymore. I notice that most requests for help to the mailing list are going unanswered as well. Fraid I get the IT department to compile and install for me, so I know relatively little about these problems. * If anybody is currently doing something interesting with Kaffe, or has any aspirations for it, please send some email to the list! We need the ideas and the traffic! Nothing interesting here. I've used Kaffe running under valgrind to detect bugs in our C code accessed via JNI. We were unable to detect these problems any other way because the Sun JVM defeated most of our usual tools. At present I dont really have an alternative to this (Windows purify started spotting additional problems once valgrind had detected the first one - they do detect different problems), but I would love to know of one. Thankfully such problems are rare, but typically are discovered at critical times - they are not keen to do a port to Linux just to find the bugs... -- Tim Bevan Principal Software Engineer +44 (0)1223 420 414 1Spatial Limited Registered in England No. 4858580, VAT Reg. No. GB 896685149 Registered Office: Cavendish House, 6 Cambridge Business Park, Cambridge, CB4 0WZ, UK ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Future directions for Kaffe
Hi everybody, It's been a quiet month on the mailing list so far. That's partly my fault, I think, since the mailing list was broken for some time. It looks like the last CVS commit was 5 weeks ago. I see Dalibor went to FOSDEM, and did some talking about Kaffe there. So I'm assuming that the project isn't dead, it's just somewhat dormant. It's been somewhat dead/dormant throughout much of it's history, but it's still here, isn't it? :-) And clearly, all the free Java runtimes and Classpath are in a state of transition, as we wait for Sun to release the rest of OpenJDK. I'd like to liven up the list a bit, and maybe start a bit of discussion on where Kaffe should go next. Here are some things I'd like to talk about: * I definitely need to do some work on upgrading the server, and fixing up the website. Currently it's running a really old version of Debian, so it needs to be upgraded. I'm just scared of all the breakage that will happen. I'm slowly building up my hosting capabilities, but it's just a hobby, and I have real life things going on, so I move at a glacial pace. If anybody wants to help out with any of that, I'd really appreciate it. I happy to keep hosting it indefinitely. * I think a wiki running on top of Kaffe would be really nice. :-) * On the other hand, there are establishing free software hosting platforms like Sourceforge, Savannah, Google Code, etc. that might work better than just running everything on our own server. Our current infrastructure is pretty much still using technology from the 1990s. We don't even have a blog or a wiki, or any continuous integration or distributed version control. I'm open to migrating things if that's what people would prefer. * Technically speaking, I'm still the project leader, by virtue of rescuing it from the ashes of Transvirtual. But Dalibor is really the guy who has been doing most of the work. I'm not really doing much with Kaffe personally, so if anybody else wants to step up and be a real project leader, feel free to volunteer. I'm still happy to keep hosting the project and helping out with the releases. * Speaking of releases, we really should do another release sometime. * I'm embarrassed to admit that I don't even have Kaffe running on my new MacBook under OS X. I got it to compile, but I couldn't get it to even run Hello World. If I spent some time on it, I imagine I could figure it out. I just haven't spent the time. I hope it still runs OK on Linux, but I haven't tried that recently either. * I also haven't been responding to emails asking me for help getting Kaffe to run. I'd like to, but since I don't even have it working for myself, I'm not really in a position to help out. I get so much spam nowadays that I hardly even use email anymore. I notice that most requests for help to the mailing list are going unanswered as well. * I'm still interested in playing with Java virtualization, and I'm very excited about OpenJDK coming out. JRuby looks really interesting to me. For my own projects, I'm guessing I'd probably use OpenJDK in preference to Kaffe in the future, since it's likely to be a lot less effort to get it working the way I want it to. * That said, I think Kaffe has been a seminal project in terms of getting free Java off the ground, and I'd hate to see it die. A lot of interesting projects have used Kaffe as a starting point. * I imagine that in the future, people will most likely look to OpenJDK as a starting point to add their enhancements. Is there still a role for Kaffe to play here? * I think Kaffe probably is still the simplest full JVM implementation that isn't just an interpreter. It's been used for all manner of exotic porting projects that might just be too hard to do using something like OpenJDK or gcj. * Kaffe is licensed under the GPLv2. So is OpenJDK. But Kaffe doesn't require copyright assignment, and we're pretty open. Sun doesn't have to vette the code going into Kaffe. That suggests that perhaps we could merge in large parts of OpenJDK, and provide a place for people to do really experimental stuff that Sun isn't going to permit in their version. Is this something we should consider? * In other words, should we go big? And merge in as much stuff as possible. That could be problematic, since Kaffe is already pretty huge. Maybe we could adopt more of a distribution approach, and break things into a bunch of modules that are all developed to work together? * Or maybe we should try to stay small? And just try to be an easily hackable, simple virtual machine with a crude compiler framework, and nothing else? That would involve jettisoning or spinning out a lot of the integration work that's been done over the last few years, I think. * I think we've been trending towards the go big direction for some time, with all the Classpath merging and other projects, and the core has been somewhat neglected. It's been really good to support Classpath this way, and
