This is the mail archive of the
mailing list for the Java project.
Re: Patch: new methods in gnu.java.net.Plain(Datagram)SocketImpl ?
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: tromey at redhat dot com
- Cc: Michael Koch <konqueror at gmx dot de>, green at redhat dot com, java-patches at gcc dot gnu dot org
- Date: Tue, 23 Sep 2003 02:51:25 -0500
- Subject: Re: Patch: new methods in gnu.java.net.Plain(Datagram)SocketImpl ?
- Reply-to: gnustuff at thisiscool dot com
>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 gnu.java.net, 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()
...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 PlatformFileDescriptor.open() 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).