Re: Classpath / GCJ java.io Merge

[Brian Jones]

"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>