classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Status update and some questions/suggestions about remaining Intel/O


From: Jeroen Frijters
Subject: RE: Status update and some questions/suggestions about remaining Intel/Orp patches
Date: Mon, 28 Oct 2002 08:52:07 +0100

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]