RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

[Chris Hegarty]

Alan,

> On 21 May 2019, at 20:05, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 21/05/2019 19:36, Chris Hegarty wrote:
>> The get/setOption methods of java.net Socket, ServerSocket, and
>> DatagramSocket, are specified to throw NullPointerException if the given
>> option name is null ( rather than UnsupportedOperationException, which
>> is currently thrown ). The implementation correctly did this in JDK 9 (
>> on *nix platforms at least ), when the methods were added, but has since
>> regressed.
>> 
>> The fix is straight forward; explicitly check the given option name
>> using Objects::requireNonNull, and update an existing regression test to
>> ensure that this behaviour does not unwittingly regress.
>> 
>> Webrev:
>>   https://cr.openjdk.java.net/~chegar/8224477/webrev.00/
>> 
> There are two parts to the issue, one is missing null change (those changes are fine), the other is throwing SocketException instead of IllegalArgumentException for bad values. Maybe you are splitting that out?

While we're here, let's address both the NPE and the IAE.

Updated webrev:
  https://cr.openjdk.java.net/~chegar/8224477/webrev.01/index.html

The code to check that specific option values are within the specified
range is independent of the particular socket type. I decided to add it
to StandardSocketOptions for two reasons: 1) co-location with its
textual range specification, and 2) is it currently only required by the
plain socket implementations. This could be located elsewhere, and
possibly shared by other code performing range checking ( since these
checks need to be consistent ).

Since the test is more involved now, I created and new separate test, so
there will be no conflict with upcoming changes to OptionsTest.

I verified the test against the NioSocketImpl, and it passes fine for
all cases except one, SO_REUSEADDR. The NioSocketImpl::setOption method
throws NPE instead of IAE when passed a null value. Easy to resolve,
then both socket implementations behave consistently, with regard to 
exceptions being thrown for bad input.

Once we agree the code changes, I'll file a CSR to track the change in
behaviour.

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190522/242b4bb8/attachment.html>