RE: FileDescriptor proposal

[Anthony Green]

[I don't believe this will reach address@hidden until my subscription
request is processed]

On Thu, 2003-04-17 at 06:02, Jeroen Frijters wrote:
> I don't really see the downside to providing my own version of
> FileDescriptor. Since its public API is so very tiny (and unlikely to
> change), I don't think the complexity of your proposal is compensated by
> the advantage of using the standard Classpath FileDescriptor.

libgcj requires that you replace much more than FileDescriptor.  All of
the classes that use FileDescriptor need to be replaced as well, because
FileDescriptor provides a number of "native" methods.

The same must be true for GNU Classpath, since it provides an "int" file
descriptor to its users to operate on.  How does IKVM work, because I
don't see a replacement for FileInputStream?  Surely you need one.  It
looks like you have non-native methods on FileDescriptor for the low
level operations which, in turn, call your IKVM system.io classes. 
libgcj could work this way also, so non-native FileDescriptor methods
call the underlying native methods.  This would isolate all of the
platform specific changes in this one class, which would be good.   The
advantage of my scheme, however, is that it replaces two non-virtual
method calls with a single virtual call.  It also won't cause problems
down the road if we introduce cross-module inlining in gcj.

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

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

AG