[Top][All Lists]
[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