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
