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

[Per Bothner <per at bothner dot com>]

Michael Koch wrote:

> I dont really see why you wanna tie FileDescriptor so much to a
> FileChannel object.

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

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

The main disadvantage I can see is having to re-write (re-arrange)
a good chunk of code.  So as an intermediate step I suggest removing
the dependency on FileChannelImpl on FileDescriptor: both would
contain a long used for Unix file descriptor or a Win32 handle.

> Unfortunately even for Posix systems int is not enough, long would be
> okay for 64 bit systems.

That is only if int is 64 bits.  My understanding is that people
generally define int as 32 bits, even on 64-bit systems.  (But of
course this is orthogonal to the discussion.)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/