Re: FileDescriptor proposal

[Anthony Green]

On Thu, 2003-04-17 at 09:47, Tom Tromey wrote:
> >>>>> "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?

No, because they are currently "native" methods, and that is not always
appropriate.
 
> What is the security model if we move all these methods to a public
> class somewhere?

The factory that creates PlatformFileDescriptors can make sure it is
being called from the proper protection domain.
 
> 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.

Everything right now assumes an underlying Posix or Windows
implementation, and uses the native file descriptor representation (an
int).  When you write to the stdout fd, the underlying system then maps
the int to a set of functions for performing work.

Imagine an embedded OS largely written in Java.  This process of mapping
an fd to something else is completely unnecessary.  We can create a
MyOSOutPlatformFileDescriptor that sends output directly to the serial
port or console.  This lets us completely avoid posix emulation.  This
specialization of PlatformFileDescriptors would be hidden within the
platform specific factory.
 
> 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.

Will they be native or non-native?

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

In order:

1. I don't want to have to write native code.
2. I don't want to be forced into using an "int" as a file descriptor.
3. I would like be able to provide subclasses of FileDescriptor like
functionality so I don't have to implement a second level of
dispatching.

AG