RFR: 8245194: Unix domain socket channel implementation [v20]

[Michael McMahon]

On Wed, 14 Oct 2020 13:17:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java line 63:
>> 
>>> 61:     /** Return the, possibly empty, set of extended socket options available. */
>>> 62:     public final Set<SocketOption<?>> unixOptions() { return unixOptions; }
>>> 63:
>> 
>> Could the name of the method - or alternatively its API doc comment - be improved to make it clear that these options
>> are **Unix Domain protocol** specific option (as opposed to Unix OS specific option). For instance, the field and
>> method could be named: `unixDomainOptions` instead of `unixOptions`?
>
> I think unixDomainOptions would be reasonable and the docs could be updated also to clearly define what each set is.

I changed it to unixDomainClientOptions to distinguish from server channel options, which there are none anyway.

>> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 267:
>> 
>>> 265:             HashSet<SocketOption<?>> set = new HashSet<>();
>>> 266:             set.add(StandardSocketOptions.SO_RCVBUF);
>>> 267:             return Collections.unmodifiableSet(set);
>> 
>> Wondering: should there be a call to `ExtendedSocketOptions` after line 266 here, even if that call just returns an
>> empty set?
>
> I suppose for consistency that would make sense, though it would be an empty set for now.

Actually, related to the last comment I just decided to make it clear the extended options are only for the client side
and it doesn't make sense to add all this code for a set of possible options that will be empty.

-------------

PR: https://git.openjdk.java.net/jdk/pull/52