RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options

[Svetlana Nikandrova]

Hi Alan,

thank you for your replay. Please let me explain a little.
For example ServerSocket and Socket have different supported options 
set, but the same SocketImpl under the hood.
Yes, SocketImpl's setOptions() and getOptions() can be modified to add 
additional check for the actual socket type that encloses that socket 
implementation, but I believe this will intricate method's logic and 
tangle the dependencies. I like it how it was done in jdk 8 - clean and 
simple - so I think it's a good idea to maintain that approach in jdk 9 
as well.

Thank you,
Svetlana

On 08.12.2015 15:56, Alan Bateman wrote:
>
> I'm sure Michael will look at this but I have a question - shouldn't 
> SocketImpl throw UOE for this case? I'm just wondering if checking the 
> supported options in setOption/getOption is just covering up an issue 
> with the SocketImpl methods.
>
> -Alan
>
>
> On 08/12/2015 12:36, Svetlana Nikandrova wrote:
>> Little reminder.
>>
>> On 03.12.2015 16:06, Svetlana Nikandrova wrote:
>>> Hello,
>>>
>>> please review a simple fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8143554
>>>
>>> See webrev here:
>>> http://cr.openjdk.java.net/~kshefov/8143554/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Ekshefov/8143554/webrev.00/>
>>>
>>> Fix added explicit check for option support to getOption and 
>>> setOption sockets' methods similar way as it was done prior jdk 9 in 
>>> Sockets class.
>>> Fix also exposed another problem with sockets' supported options: 
>>> JDK-8143923 <https://bugs.openjdk.java.net/browse/JDK-8143923> that 
>>> cause new test failure test/java/net/SocketOption/OptionsTest.java. 
>>> I added test to the ProblemList.
>>>
>>> Thank you,
>>> Svetlana
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20151208/e7ee39d3/attachment-0001.html>