RFR 8245194: Unix domain socket channel implementation

[Michael McMahon]

On 18/08/2020 18:07, Alan Bateman wrote:
> 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.
>

I have refactored this now so the existing Net class is basically 
unchanged and a new UnixDomainNet contains all the new code. Also, the 
unnecessary casting is all gone now.


> 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.
>
Done.

> Is sun.nio.fs.UnixUserGroupUtil used anywhere?
>
Yes, it is used in the extended socket option impl code.


> 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.
>
As I mentioned the other day, I wasn't able to use the suggested method 
on Windows which returns an absolute path. So, I added a method to 
WindowsPath which returns the path in the expected UTF-8 encoding as a 
byte[]. Let me know what you think of that.

There is a fair bit of other refactoring and simplification done also. 
Next version is at:

http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/

Thanks

Michael.