RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

[Alan Bateman]

On 27/04/2016 10:04, Chris Hegarty wrote:
> On 26 Apr 2016, at 18:21, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>> I took a second pass over it. One thing that I'm wondering about is whether BaseExtendedSocketOptions + Support should be collapsed into one abstract class ExtendedSocketOptions (or better name) with 3 instance methods and 2 static methods. It's an internal interface so not a big deal but I think it would be a bit cleaner and allowed the oddly named "Support" to go away.
> This works out quite nice.  Webrev updated in-place:
>    http://cr.openjdk.java.net/~chegar/8044773/jdk/
>
I think this looks good.

The NoExtendedSocketOptions constructor should be able to just use 
Collections.emptySet() as that is unmodifiable.

"no extended options" - it might be better to include option.name() in 
the message.

Otherwise looks okay to me.

-Alan.