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

[Per Bothner <per at bothner dot com>]

Mohan Embar wrote:

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

That's a good point.  Perhaps the 'channel' field of a FieldDescriptor
should be a java.nio.channels.spi.AbstractInterruptibleChannel or just
a Channel.  However, that doesn't have the 'force' needed for 'sync'.

How about this:

class FileDescriptor
{
  Channel channel;
  public void sync () throws ...
  {
    if (channel instanceof FileChannel)
      ((FileChannel) channel).force(true);
  }
  public boolean valid () { return channel.isOpen(); }
}

> I personally think that RawData is the proper type for Windows

I agree.

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

This I'm not convinced of.

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

An array?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/