RFR 8241305: Add protocol specific factory creation methods to SocketChannel and ServerSocketChannel

[Michael McMahon]

On 08/05/2020 11:52, Alan Bateman wrote:
> On 08/05/2020 10:41, Michael McMahon wrote:
>> Hi Alan
>>
>> I think we have dealt with your comments below. As regards the 
>> question about platform
>> specific differences shown by the OpenAndConnect test, yes much of it 
>> results in the case
>> where the server binds to a wildcard address and then the client 
>> connects to that.
>> It was a surprise to me that the API supports that at all, which it 
>> does. So, the test
>> is really just documenting the differences. It does seem to be mostly 
>> windows that disallows it.
> It looks a bit strange to try connect a DatagramChannel to a target 
> that is any address. Daniel, Patrick and I have chatted about a few 
> times. It comes up with tests that bind to the wildcard address and 
> then use getLocalAddress to get the target address for the test. One 
> possibility is to translate it to a specific address (as is done in 
> SocketChannel and java.net.Socket) but that is something for a 
> separate issue and not clear to me that we should adding a test for it 
> here.
>
> Would it possible to summarize the other Windows specific issues that 
> are being "documented" ?
>
> -Alan


It's not just Windows and it's hard to discern patterns from the test, 
the way it is structured,
but another one would be binding the first socket to an IPv4 address 
(loopback or actual local address)
and binding the second socket to an IPv6 equivalent. This fails for 
SocketChannel on all platforms,
and also for DatagramChannel on all platforms except MacOS.

If you want I can cut the test back to only test positive scenarios that 
should work across all platforms.

Michael