RFR 8245194: Unix domain socket channel implementation

[Michael McMahon]

On 13/08/2020 09:58, Alan Bateman wrote:
> On 12/08/2020 13:01, Michael McMahon wrote:
>> Thanks for the reviews of the API for this work (JEP 380). The CSR 
>> has been approved.
>>
>> So, I would like to continue with the implementation review. The full 
>> webrev can be found at:
>>
>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.8/
>>
>> Comments welcome.!
> 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.
>
> -Alan
>
>
Thanks for the review. Just on the Win32 variant, getPathForWin32Calls 
seems to return a Unicode/wide character string, but the windows API 
expects UTF-8. Also, it normalizes the path including converting to 
absolute form. (Haven't checked, but maybe getByteArrayForSysCalls does 
that too). But, we need to support relative paths in this API, given the 
severe constraints on the length of Unix domain socket names. There 
probably is still an issue with the right character set being used. So, 
I will look into fixing that (maybe by adding suitable methods to 
WindowsPath and UnixPath if necessary).

Thanks,

Michael.