Re: java.nio ramblings (was Re: What's Left for MingW 3.3)

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi Michael,

>> I don't know what they JDK does, but see a possible solution in the
>> context of GCJ:
>>
>> - move java.net.PlainSocketImpl to gnu.java.net (which doesn't
>> exist yet) and make it (necessarily) public; enhance it to support
>> all the functionality needed for java.nio.channels - create a
>> package-private subclass of java.net.ServerSocket called
>> java.nio.channels.ChannelServerSocket (you could also make this a
>> private nested or inner class of ServerSocketChannelImpl) and in
>> its constructor create and delegate to PlainSocketImpl
>> - for the non-ServerSocket-related functions in
>> ServerSocketChannel, delegate directly to the PlainSocketImpl that
>> ChannelServerSocket is holding onto
>>
>> This would solve both of the problems I mentioned.

>Thats a good solution. This implies that we dont support user supplied 
>implementations of SocketImpl and DatagramSocketImpl. I think thats 
>okay.

When you don't say "don't support user-suppled implementations", do
you mean:

- for the case of constructing an explicit instance of java.net.Socket
  using one of its overloaded constructors (let's call this case A)?
- or the ServerSocket returned by java.nio.channels.ServerSocketChannel.socket()
  (case B)?

If you mean case A, I don't see how my solution precludes user-supplied
implementations.

If you mean case B, the java.nio specification explicitly disallows user-supplied
implementations. See:

http://java.sun.com/j2se/1.4.1/docs/api/java/nio/channels/ServerSocketChannel.html

("...nor is it possible to specify the SocketImpl object...")

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/