On 27 Apr 2016, at 20:13, Alan Bateman <alan.bate...@oracle.com> wrote:
> On 27/04/2016 10:04, Chris Hegarty wrote: >> On 26 Apr 2016, at 18:21, Alan Bateman <alan.bate...@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.
