--- Begin Message ---
|
Subject: |
FileDescriptor proposal |
|
Date: |
16 Apr 2003 23:12:57 -0700 |
[I wrote this in the context of gcj, but I suppose the changes should
really be in GNU Classpath and then merged into libgcj. I cannot post
to the Classpath list since I am not subscribed right now. I'll
subsribe now and forward it to the list if it survives initial
discussion here...]
I'd like to propose some changes to FileDescriptor. The current scheme
requires an underlying implementation written in native code, and that
the platform's descriptors be representable in 32-bits. We know this
will be a problem for 64-bit Windows systems once they arrive, and I'd
like to support systems where the "native" bits are actually written in
java, not C/C++. This isn't possible today. The changes I'm proposing
clean all this up with a small amount of additional overhead.
FileDescriptor's public interface is actually very small. libgcj's
FileDescriptor also provides some package private methods which are used
within libgcj.
My basic plan is to move all of these package private methods to a new
abstract class called gnu.java.io.PlatformFileDescriptor (for lack of a
better name). java.io.FileDescriptor will have one new package private
method for returning the PlatformFileDescriptor associated with that
FileDescriptor. All of the code that used to cache a FileDescriptor and
call its package private methods will now cache and use the result of
FileDescriptor.getPFD().
PlatformFileDescriptor.getFD() may be used to get a FileDescriptor back
(needed, for instance, by FileInputStream.getFD()).
Subclasses of PlatformFileDescriptor provide all of the target specific
code. They are created by a factory class referenced in
gnu.classpath.Configuration, which is determined at configure time.
These changes will make the *FileDescriptor open/write/read/etc methods
"virtual" when today they are not (FileDescriptor is a "final" class).
The upside of this change is that Classpath/libgcj will be able to
support a wider variety of systems. The only alternative for some of
these systems right now is to provide their own version of
FileDescriptor and related classes instead of using Classpath/libgcj's
(IKVM and jx are two systems I know of that do this today).
AG
--- End Message ---