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

[Michael Koch <konqueror at gmx dot de>]

On Sun, Jan 25, 2004 at 09:23:06AM -0800, Per Bothner wrote:
> 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.

The problem with FileDescriptor is that it should not extend another new
class/implement another new interface. And you cannot subclass it
because its final. There is no really good design possible. The only
bad things we can do is to add private or package-private methods/fields.
FileDescriptor is used for network stuff too. Making it a wrapper for
FileChannel would be far away from good design as heaven is from hell.
I dont know what SUN intended with this class or how they implement
stuff (and I dont wanna know either). The only clean way I can think of
is put the implementations (for Posix, Win32, etc) into a new class
(probably located in gnu/java/io or so) and then use this from
java.io and java.nio. Thats a major rewrite but the cleanest thing I can
think of.

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

int in java is always 32 bit. Even on 64-bit systems. In contrary to C.


Michael