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

[Chris Hegarty]

On 27 Apr 2016, at 20:13, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 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.

Great. Thanks.

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

D’oh! Silly me.

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

Yes, that would be better.

> Otherwise looks okay to me.

I’ll make the above changes before pushing.

-Chris.