RFR  8044773: Refactor jdk.net API so that it can be moved out of the base module
chris.hegarty at oracle.com
Wed Apr 27 19:16:53 UTC 2016
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:
> I think this looks good.
> 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.
More information about the build-dev