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: Patch: new methods in ?

Hi People,

>As I understand it, this would change us from having final methods to
>virtual methods for everything in FileDescriptor.  With the new ABI,
>that's unlikely to be a performance penalty.

The key point that Anthony is making is that there doesn't really seem
to be a choice here. For me, the overriding goal here is the total eradication
of int being used as some sort of handle, which, as Anthony pointed out,
is dead wrong on Win64.

>There are two open questions, still:
>- What is the security model?
>- Will this approach be suitable for java.nio?

Design choices for java.nio have led us to move several formerly package-private
classes to public ones in, for example. I don't see how this
would be less secure than that design choice.

As for whether this is compatible with nio, my gut feeling is that anything, nio or not,
which relies on a file descriptor less portable than Anthony's proposal couldn't
possibly work on both Win64 and POSIX. That wouldn't preclude subclassing
FileDescriptor, as discussed elsewhere in the thread, but why subclass when you
can delegate (especially via an interface - see my closing questions)?

>Some of the sample code (AG supplied some, if you read through the
>thread you can find a link) is kind of gross, imo.  For instance, now
>FileInputStream has two fields, "fd" and "pfd". 

- Can you identify any other grossness other than these two fields?
- Would replacing pfd as a private field by a helper method like this:

  private PlatformFileDescriptor getPFD()
    return fd.getPFD();

  ...cause it to get inlined away?

>Other aspects of the code are clearly cleaner though, for instance
>"PlatformFileDescriptor" is a nice abstract base class.


- Why are PlatformFileDescriptor[Factory] ABCs instead of interfaces?
- Why does return int instead of void?
  Don't we want to eliminate this? If someone really needs the underlying
  handle. You could either return it as a RawData (bleah) or else force
  the caller to downcast the PlatformFileDescriptor (bleah).

-- Mohan

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