On Tue, 2006-01-31 at 22:00 +0100, Roman Kennke wrote: > I get the impression that there > is a general opposition against real portability concerns within the GNU > (Classpath?) project. Correct me if I am wrong. There certainly are > parties that have portability demands that go beyong posix. Yes. Many parties probably do, or will do eventually. It's in the nature of free software to get ported, somehow, to anything people want to run it on. ;) But I doubt there are many developers inside GNU Classpath as a whole who'd be interested in maintaining non-POSIX code, since most VMs either support only POSIX, POSIX + something special or only something special, so that the set of stuff that's got a fair chance of being communally maintained since it is useful to more than a single VM boils down to POSIX alone. That's pretty much the stuff that has a fair chance of getting love by diffeent VMs in the common tree. So if, theoretically, Kaffe was ported to run on top of Ruby[0] it would make most sense to keep the maintenance & the associated busywork for the Ruby port of GNU Classpath's native libraries in KaffeOnRuby, rather than trying to maintain it inside GNU Classpath. Same if JamVM was ported to 16-bit Minix 2 on Amiga: the necessary changes to the native layer would be too invasive to bother the POSIX-only VMs with, as they'd add some burden without necessary immediate gratification for posix-only VMs. Immediate gratification good, maintenance burden bad. :) I think the hard question is how to make the native layer stuff such that a) most vms can profit from it, in particular when starting from ground up and b) it is easy enough to embrace and extend for those cases where it does not fit well, without forcing one to wholesome fork the native layer, or to maintain the odd, single-VM cases inside GNU Classpath. The answer to a) seems to be POSIX for the reasons given above, and to b) seems to be something like Guilhem's work on the native layer. > Granted, > Aicas is a commercial party and cannot publish every port. There is also > Kaffe, which is 100% GPL and now also suggest something similar like the > target layer, only somewhat nicer, and again it seems to turn out to be > a fight against windmills. A major issue is that for green threads (i.e. jthreads) in Kaffe, we'd have to make sure that we can disable interrupts before invoking a system method, and enable them before we exit again. If we don't do that, than bad things can (and do ;) happen. That's a pretty Kaffe-specific need, though, so it may not make sense to make room for it in GNU Classpath, unless it is accompanied by some other, instant gratification, like looking very much like plain old POSIX. In theory, if we're lucky, Kaffe may also be able to get by using AspectC++[1] or something equivalently weird to weave in the stuff we need for jthreads. In practice, I don't think anyone has done something like that yet, though. ;) cheers, dalibor topic [0] Just imagine the potential for book sales! ;) [1] http://www.aspectc.org/Publications.6.0.html
