This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]