JDK-8234811 : MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.net
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 14
  • Submitted: 2019-11-26
  • Updated: 2019-11-27
  • Resolved: 2019-11-27
Related Reports
CSR :  

Change implementation of `MulticastSocket::getOption(StandardSocketOption.IP_MULTICAST_IF)` to return  `null` rather than a dummy object if the option has not been set.


`MulticastSocket::getOption(StandardSocketOptions.IP_MULTICAST_IF)` returns a dummy `NetworkInterface` object, instead of `null` if the option has not been set.
By comparison, `DatagramChannel` and `DatagramChannel`'s socket adaptor will return `null` in the same circumstance, which is a much more intuitive behavior, and conforms to the behavior specified by [StandardSocketOptions.IP_MULTICAST_IF][1]:

> The initial/default value of this socket option may be null to
> indicate that outgoing interface will be selected by the operating
> system, typically based on the network routing tables.


Change the return value of MulticastSocket::getOption(StandardSocketOptions.IP_MULTICAST_IF) to be `null` if the option has not been set.
By long standing behavior, `MulticastSocket::getNetworkInterface` returns a dummy interface when no network interface has been set. For backward compatibility and to avoid introducing unnecessary risks the behavior of this method will remain unchanged. Only the behavior of the  `MulticastSocket::getOption(StandardSocketOptions.IP_MULTICAST_IF)` method is changed. This method was added in Java SE 9 so the risks should be limited.


There is no change to the specification. However `MulticastSocket::getOption(StandardSocketOptions.IP_MULTICAST_IF)` will now return null if the option has not been set, as specified by [StandardSocketOptions.IP_MULTICAST_IF][1].

  [1]: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/net/StandardSocketOptions.html#IP_MULTICAST_IF
Clarified wording of summary; moving to Approved for JDK 14.

Note: This fix could also be backported to JDK 11 to limit the risk of having new code depending on the bad behavior.

I think the compatibility risk of this change is low. As with JDK-8233296, it is unlikely that getOption(IP_MULTICAST_IF) is widely used as getOption is new since Java SE 9. Additionally, MulticastSocket does not specify that it supports this socket option. Back-porting this change to a JDK 11 update will help to mitigate any compatibility issues in the future.

This is not the first CSR where I've seen mention of a possible backport to an 11 Update. As a matter of process, will a separate CSR be filed for such a backport, or is the intent to cover the backport in this CSR? If the former, which I suspect it is, then the "possible" backport should have no bearing on this CSR and should be removed from the risk section. The behaviour change is reasonable for a major release of the Java SE platform, it should be given different consideration for an update release, but that is a matter for the 11 Update maintainers.