[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Classpath / GCJ java.io Merge
From: |
Brian Jones |
Subject: |
Re: Classpath / GCJ java.io Merge |
Date: |
27 Feb 2003 18:10:38 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
"Aaron M. Renn" <address@hidden> writes:
> One problem is that it is not just the native methods that are different.
> I think it would be relatively easy to write a CNI and a JNI version of
> the code as there is not a huge amount of native code to write for
> IO and networking. The problem is that the entire implementation strategy
> of the classes is different. For example, gcj relies heavily on delegating
> to OS file access methods in the FileDescriptor class, which Classpath
> doesn't use at all. The challenge would seem to be getting agreement
> on what native methods need to be written and what their signatures are.
Between gcj and classpath there is a difference of opinion on whether
to drop into native code (CNI) at every opportunity or not and I think
it has affected the way some things are handled. However I think when
designing for JNI you do not hinder library performance using CNI but
the opposite is not true.
I'd like to see our I/O implementation handle 64-bit filesystems and
all the native libs be 64-bit compatible (i.e. no assuming pointers
are ints, file handles are ints, etc.).
--
Brian Jones <address@hidden>