RFR 8245194: Unix domain socket channel implementation

[Alan Bateman]

On 26/08/2020 15:24, Michael McMahon wrote:
>
> 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/
>
Adding a method to WindowsPath to encode the path using UTF-8 is okay 
but I don't think we should be caching it as the encoding for sun_path 
is an outlier on Windows. I'm also a bit dubious about encoding a 
relative path when the resolved path (before encoding) is > 247 chars. 
The documentation on the MS site isn't very completely and I think there 
are a number points that require clarification to fully understand how 
this will work with relative, directly relative and drive relative paths.

In the same area, the new PathUtil is a bit inconsistent with the 
existing provider code. One suggestion is to add a method to 
AbstractFileSystemProvider instead. That is the base class the platform 
providers and would be a better place to get the file path in bytes.

-Alan.