Re: FileDescriptor proposal

[Tom Tromey]

>>>>> "Anthony" == Anthony Green <address@hidden> writes:

Anthony> http://people.redhat.com/green/pfd-sketch.tar.bz includes
Anthony> draft versions of java/io/File*.java and the new
Anthony> gnu/java/io/* classes described in my proposal.

I see.

Anthony> Changes to the FileDescriptor users are pretty small.  It
Anthony> should be obvious how this scheme will easily let us create
Anthony> stream specific handlers and how we no longer have "int" or
Anthony> native code dependencies.

I think something similar to this can already be done with our
existing approach.  You just have to replace parts of FileDescriptor,
but that's ok since you'd be building for a different platform anyway.
I think of FileDescriptor as exporting an API that we happen to
provide an implementation for.  In libgcj anyway we'll have a
somewhat different implementation of the same API.  The point isn't
necessarily to make FileDescriptor the same everywhere, but to make
sure all its callers are.


I've noticed I'm being pretty resistant to your idea though.  And I
don't think that is fully warranted.  It's unlikely that another
method call here or there is going to be a big problem; I/O is slow.
(Ideally somebody would benchmark this before we make a change
though.)

The proposed solution doesn't really add much complexity (to my mind
it is similar to what we're already doing, just rearranged a bit --
but back in the real world it is definitely easier to understand as an
API).  The security access stuff would have to be addressed.

One open question is how your approach would work with java.nio.  I
think this remains a deficiency of the approach currently in cvs.
Maybe Michael Koch could say something about what is needed there.
For all I know your approach will make java.nio easier.

Tom