Re: More java.io

[Aaron M. Renn]

Tom Tromey (address@hidden) wrote:
> Aaron> 2.  On java.io.File, similar to the FileDescriptor stuff, I'd
> Aaron> like to propose a unified provider interface.  Comments:
> 
> Aaron> o I like to pass the filename to avoid gratuitous JNI lookups.
> Aaron> o I do not want to adopt the "overloaded" stat and access methods of
> Aaron>   gcj, I'd rather have one method per lookup
> Aaron> o I'd like to name consistently with FileDescriptor
> Aaron> o Minimizing native functionality, I want to return a full directory
> Aaron>  listing to Java and filter at that level instead of the gjc approach.
> 
> These all sound good.

Cool.
 
> Aaron>   boolean nativeCreate(String name);
> 
> These should all be static if they take the name explicitly.

Well, it is similar to what I did with FileDescriptor. Everything
probably could have been static there as well because we pass in the
file descriptor.  Still, it is solely to keep from having to do a
painful JNI field lookup and the method really is associated with
an instance of File.  Is there any particular reason to prefer
instance vs. static methods or vice versa?
 
> I think for FileDescriptor libgcj may remain with its own
> implementation, to avoid another layer of calls for all the I/O
> operations.  (Though maybe this is foolish optimization.  I'm not
> fully decided yet.)  In any case we'll standardize on the Classpath
> API so that all the classes that use FileDescriptor will be merged.

Good.  If you want changes, feel free to ask (or make them yourself).
The new FileDescriptor API is very close to the gcj one so implementing
it would be easy.  If you want to throw that "position" back in there
as a private instance variable, I'm ok with that too.

Brian says we're waiting for some additional native code contributions.
I want to figure that out then get File modified.

-- 
Aaron M. Renn (address@hidden) http://www.urbanophile.com/arenn/