RFR: 8245194: Unix domain socket channel implementation

[Alan Bateman]

On 07/09/2020 13:14, Michael McMahon wrote:
>> 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.
>>
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>
The file system provider shouldn't know anything about Unix domain 
sockets so I prefer not to have "UnixDomain" in the name of this method. 
I also would prefer if null is an exception so that it is consistent 
with the other methods.

I think it would be useful to also summarize how the bind/connect works 
on Windows. For example, suppose the working directory is 240 characters 
and the UnixDomainSocketAddress is to a simple relative path of 20 
characters. If I understand correctly, the proposal will encode the 
simple relative path (not the resolved absolute path) to bytes using 
UTF-8 so it will probably be 20+ bytes in this case. This hould be okay 
but inconsistent with the rest of  file system implementation which will 
use the long form. Also if the name is long then it won't use the long 
path prefix (\\?\) but instead rely on failure because the resulting 
sequence of bytes when encoded is > 100, is that correct?

-Alan.