Re: FileDescriptor proposal

[Tom Tromey]

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

Anthony> libgcj requires that you replace much more than
Anthony> FileDescriptor.

Can't you just reimplement the package-private methods of FileDescriptor?

What is the security model if we move all these methods to a public
class somewhere?

Anthony> Another advantage of my scheme is that FileDescriptor.getPFD
Anthony> can provide stream specific implementations of
Anthony> PlatformFileDescriptor.  For instance, my System.out
Anthony> PlatformFileDescriptor can immediately do the right thing for
Anthony> my target, rather than rely on yet another level of
Anthony> indirection in the underlying IO system.  This is something
Anthony> I'd really like to do.

Can you be more specific here?  I don't think I follow.

Anthony> Forking bits of libgcj/Classpath also seems wrong and
Anthony> unnecessary.

Aaron did a lot of work recently on the Classpath FileDescriptor and
friends.  Many of the surrounding classes are fully merged.  The plan
here is to have a generic FileDescriptor that can be used by any
Classpath client (and that should include any host port).

The idea is that the package-private FileDescriptor API will remain
consistent across users, e.g. methods like write and close.  This lets
a given Classpath user reimplement FileDescriptor, if desired, without
also having to reimplement the classes that use it.  For instance in
libgcj I'm planning to remove the second layer of calls, so you won't
see the foo/nativeFoo split you see in Classpath.  However, the
package-visible API will be the same.

Classpath currently assumes that -1L is an invalid fd representation
on all platforms.  That may not be so great.  It's easy to fix though;
we can add a new `static final' field that is set by
FileDescriptor.nativeInit.


That's a description of the current plan.  What is it that you think
needs to be changed?  I'm particularly curious about the System.out
thing.

Tom