On Wed, 14 Oct 2020 13:17:01 GMT, Michael McMahon <micha...@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
