JDK-8234626 : Different Socket's:: supportedOptions() behavior mismatch from spec.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 9,10,11,12,13
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-11-22
  • Updated: 2024-11-04
  • Resolved: 2019-12-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8235141 - Specify the required standard socket options for the socket types in the java.net package
Relates :  
JDK-8235141 - Specify the required standard socket options for the socket types in the java.net package
Description
It's observed that the Socket/DatagramSocket/ServerSocket :: supportedOptions()  method returning some options whose getOption() is throwing SocketException.

It needs to be clarified from the spec.
Comments
Closing as a duplicate of JDK-8235141.
23-12-2019
The socket options returned by supportedOptions() may include non-standard options. Considering only the Java SE specification, the caller of said method has no idea of the semantics of these non-standard socket options. For example, what the type of the option value is, whether or not the option is retrievable or settable, etc. An option may always, unconditionally, throw an exception if retrieved or set, or may throw on Tuesdays. The JCK is best off filtering out any non-standard options from the set of options returned by supportedOptions. Here is an example of some options that are return for a java.net.Socket on Linux: jshell> var byName = Comparator.<SocketOption,String>comparing(SocketOption::name) byName ==> java.util.Comparator$$Lambda$27/0x0000000800b7d040@246b179d jshell> var s = new Socket() s ==> Socket[unconnected] jshell> s.supportedOptions().stream().sorted(byName).count() $6 ==> 11 jshell> s.supportedOptions().stream().sorted(byName).collect(toList()) $7 ==> [IP_TOS, SO_KEEPALIVE, SO_LINGER, SO_RCVBUF, SO_REUSEADDR, SO_REUSEPORT, SO_SNDBUF, TCP_KEEPCOUNT, TCP_KEEPIDLE, TCP_KEEPINTERVAL, TCP_NODELAY] ( the TCP_KEEPxxx options just happen to be retrievable and settable ) Same example with non-standard options filtered out: jshell> s.supportedOptions().stream() .filter(StandardSocketOptions::isStandardSocketOption) .sorted(byName).count() $9 ==> 8 jshell> s.supportedOptions().stream() .filter(StandardSocketOptions::isStandardSocketOption) .sorted(byName).collect(toList()) $10 ==> [IP_TOS, SO_KEEPALIVE, SO_LINGER, SO_RCVBUF, SO_REUSEADDR, SO_REUSEPORT, SO_SNDBUF, TCP_NODELAY] --- I would be convenient if Java SE provided a way for determining if an option is standard or not, e.g. public final class StandardSocketOptions { /** * Tells whether or not the given socket option is one of the * <em>standard</em> socket options. * * @param option a socket option * @return true if and only if the given socket option is one of * the standard socket options */ public static boolean isStandardSocketOption(SocketOption<?> option) {...} ... }
22-11-2019
The getOption(SocketOption) defined by Socket, ServerSocket, DatagramSocket, and the NetworkChannels in the java.nio.channel all specify that they throw IOException when they fail. A SocketException is an IOException so already covered by the specifications. The linked issue with the Solaris specific SO_FLOW_SLA socket option may be worth a discussion. It may be surprising to learn that reading this socket option when there is no flow configured (via the socket option or flowadm) will fail but that is just the way this option works. It also fails when the process doesn't have root permission. Both are these points would be good to clarified in ExtendedSocketOptions.SO_FLOW_SLA. It might be more user-friendly for getOption to return null when there is no flow configured but that does not remove the possibility that the underlying getsockopt will fail for other reasons.
22-11-2019