Hi, On Fri, 2003-02-28 at 01:50, Tom Tromey wrote: > >>>>> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes: > Aaron> o Figure out the JNI/CNI situation and merge the native > Aaron> backends with gcj. > > I don't think we should let this hold up Classpath 1.0. libgcj will > probably continue to have some divergences with Classpath for quite > some time. The CNI thing is just part of it. In other places we have > divergences for performance reasons (see ResourceBundle) or due to how > our VM is implemented (see Reference).
I agree with Tom here. I think it is best if GNU Classpath sticks with providing only a JNI/POSIX/C based native reference implementation. We just need to define the VMNative/Interface parts well enough for 1.0 to make a CNI/C#/Java/WhatEver implementation easy. Then if people want a CNI implementation of those VMInterface classes they can just look at the libgcj implementation. I think that ResourceBundle is a good candidate for introducing a VMResourceBundle class that defines the (callback) methods that a VM might want to implement for optimization (Classpath would supply a default java based implementation). Cheers, Mark _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
