Hi, On Sunday, October 27, 2002 12:41, Andy Walter wrote: > On Sunday 27 October 2002 02:22, Mark Wielaard wrote: > > - java/io/Object*Stream.java. We had these classes merged > with libgcj > > but they are diverging again. This is code I don't know > much about and > > has some very subtle issues that are easy to get wrong. One > thing I like > > about the libgcj version is that it has a lot less native > methods and > > does more with reflection. That makes the code much more > portable. Is > > there a (performance?) reason for using so many native calls? > > To me, avoiding native methods as often as possible is > preferable as well.
I agree. I'm not using any JNI in my VM for the Classpath native methods (although my VM does support it [but it isn't completely done yet]), for one simple reason: I want my VM to be runnable in a sandbox, and native code requires full trust. > But > I'm not so sure whether using reflection in java.io.* is a > such a good thing. > Generating binaries that contain all needed classes > (including those of the > library) is an easy job, as long as reflection is not used. Mark was talking specifically about ObjectInput-/ObjectOutputStream and they require some sort of reflection anyway. The current implementation uses JNI reflection, but IMHO it would be preferrable to do the reflection from Java. I think this has the potential to be faster too. Regards, Jeroen _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
