RFR 8245194: Unix domain socket channel implementation

[Alan Bateman]

On 13/08/2020 09:58, Alan Bateman wrote:
> This is great work but I do have quite a lot of comments.
>
> One thing that to start with is Net.unixDomainConnect/unixDomainBind 
> are taking String objects. The encoded bytes are already in UnxPath. 
> Also WindowsPath has the file path to specify to Win32 calls. So I 
> think this has to change to use getByteArrayForSysCalls and 
> getPathForWin32Calls, and this will mean refactoring because it is 
> platform specific. It will mean that the native code is simpler as it 
> will be passed a pointer for sun_path.
One other issue with the current implementation is that I think 
overburdens sun.nio.ch.Net with several helper and native methods for 
Unix domain sockets that probably should start out on the Unix domain 
socket / server-socket implementation classes instead. That would allow 
methods such as Net.localAddress to continue to return an 
InetSocketAddress for now and will avoid the changes and casting at the 
10+ use sites. It would also avoid the naming issues that the new 
methods bring.

For SocketChannelImpl/ServerSocketChannelImpl, the convention is implXXX 
rather than xxxImpl so it would be good to rename the methods to keep 
things consistent. I would also prefer if we could avoid the xxxSpecial 
methods. It might be simpler to start out with all the socket option 
support in the sub-class, it would at least make it easier to review.

Is sun.nio.fs.UnixUserGroupUtil used anywhere?

I'm sure I will have comments for later rounds but I think we should 
first get agreement for the connect/bind/etc. methods to use the 
platform representation from UnixPath/WindowsPath to avoid using a 
different encoding implementation.

-Alan