>> This sounds like a good plan... I never heard of a GNU/Linux system
>> that didn't include Perl, but certainly some other unixes don't.
Bernd> One of the implications of Java for free software is that it
Bernd> could eventually make large inroads into Win32/other
Bernd> non-UNIX. Vice versa, Java applications might minimize the
Bernd> migration pains for GUI intensive apps, from non-UNIX to
Bernd> Linux. Is GNU/Linux the limit of what Classpath is aiming at?
I'm not sure how I feel about JNI/CNI compatibility using a language
we make up. It does seem attractive, but I wonder how many lurking
pitfalls there are.
Another approach would be to modify gcjh to generate stub classes that
look like CNI on one side but make JNI calls on the other side. This
also has pitfalls (as in, it might not even be possible to do, given
direct field references in CNI code -- there's no good way to
introduce accessors. I'm not entirely certain this is the case, since
my knowledge of C++ hasn't kept up with the language).
Either way we should definitely investigate these (and other) options
instead of just writing all the code twice. That way lies agony.
I'd like to point out that using Perl as part of the build process is
not a portability killer. It all depends on how you do it. For
instance, in libgcj we use Perl to generate tables in some situations
(eg, the tables used by Character are generated by a Perl script). In
this case we check in the generated tables since they change
infrequently; most developers never run the scripts.
libgcj is very portable (though perhaps not widely ported). It can
run on systems without a filesystem, for instance. I can't speak for
Classpath, but I can say that libgcj's goal is and will continue to be
portability to a wide variety of systems (including Windows, should
someone do the port).
Tom
