Re: FileDescriptor suggestion [Was: FYI: Patch: java nio file locking]

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi People,

Sorry I came late into this discussion. I'm going to reply to bits
and pieces from the various posts without doing this in separate
emails.

>From this:

http://gcc.gnu.org/ml/java-patches/2004-q1/msg00309.html

Michael>> Why should we write two or more FileChannel implementations when we only
Michael>> need one with just some different native implementations ?

Per> I agree that it seems simpler to stick with that model for now.
Per> However, my understanding of the "PlatformFileDescriptor" proposal
Per> is that some people want separate platform sub-classes.  That does
Per> have some potential advantages (can write platform-specific code
Per> in Java, rather than native).

Per> But for now, I propose being less radical:
Per> gnu.java.nio.channels.FileChannelImpl would have a single
Per> FileChannelImpl.java, with natFileChannelPosix.cc etc
Per> renamed with a symlink to natFileChannelImpl.cc.

...which brings us to what we were planning :). However, I still think
that PlatformFileDescriptor (or some variant thereof) should be factored into
all of this.

>From this:

http://gcc.gnu.org/ml/java-patches/2004-q1/msg00300.html

Per> Both are wrappers around Unix file descriptors (or equivalent handles).
Per> Either both contains a file descriptor, or one is a wrapper around the
Per> other.  The former solution requires native code for both classes, as
Per> well as possible platform-dependent subclasses, so it seems better to
Per> have one class just be a wrapper for the other.

Per> Having FileDescriptor be a wrapper for FileChannel wins over the converse:
Per> + Better performance using nio.
Per> + There are more public or protected methods in FileChannel, so we
Per> need less indirection going from FileDescriptor to FileChannel
Per> than vice versa.
Per> + FileChannel is an abstract class; the specification requries us
Per> to subclasss it.  FileDescriptor is not an abstract class, so we're
Per> not quite so close to spec if we return a subclass.  The alternative
Per> of using a PlatformFileDescriptor field in FileDescriptor means
Per> extra indirection, which we don't need when subclass FileChannel.

I like the spirit of this, but the problem I have with the substance is that,
as Michael pointed out, FileDescriptor is also used for the java.net classes
and java.nio socket classes.

If you look at the API for FileChannel, there are a lot of methods (lock, map,
tryLock, position, size) which have no relevance to socket-based file
descriptors, which leads me to believe that FileDescriptor shouldn't be
considered a superset of FileChannel and that the inverse makes more
sense. And throwing in a PlatformFileDescriptor into the mix would make
things perfect, er, um, better.

Finally from this:

http://gcc.gnu.org/ml/java-patches/2004-q1/msg00308.html

Per> Yep - and I'm inclined to agree that using Java long may be a good
Per> idea anyway just for the sake of 64-bit Windows (if/when that happens).

I personally think that RawData is the proper type for Windows (and for
all platforms for that matter). I mentally think "void*" when I think RawData.
On Windows, OS-native file and socket descriptors are pointers (HANDLE
and SOCKET are typedefs for pointers). It makes more sense to tie ourselves
to a pointer type (which is probably guaranteed to be the largest possible
width (32 bits on 32-bit systems, 64 bits on 64-bit systems, 128 bits on...))
than to pigeonhole ourselves into the next "upgrade" of a fixed-width data
type that will be insufficient when the next width comes along.

I consider the use of ints for file descriptors on POSIX-based platforms to
be an anachronism from which we should try to mentally free ourselves.
(Of course, Windows has these too for its POSIX-lookalike API functions,
and I don't even want to think about what kinds of funky mapping they're
doing under the covers to make this work.)

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/