JDK-8237352 : Update DatagramSocket to add support for joining multicast groups
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-16
  • Updated: 2021-03-05
  • Resolved: 2021-02-08
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.
JDK 17
17 b09Fixed
Related Reports
Blocks :  
JDK-8235139 - Deprecate the socket impl factory mechanism
CSR :  
JDK-8260667 - Update DatagramSocket to add support for joining multicast groups
Relates :  
JDK-8263080 - Obsolete relationship in MulticastSocket API documentation.
Description
Evaluate how to write a custom DatagramSocket/MulticastSocket without using DatagramSocketImplFactory.

This issue has been file as a result of a discussion raised during a code view for 8236925, see https://mail.openjdk.java.net/pipermail/net-dev/2020-January/013514.html

Though DatagramSocket has a protected constructor that allows to pass a DatagramSocketImpl instance, MulticastSocket doesn't. 
There are two ways to provide a complete custom implementation of DatagramSocket:
  - Subclass DatagramSocket and pass a custom DatagramSocketImpl instance that reimplement the whole functionality
  - Subclass DatagramSocket and pass a non functional DatagramSocketImpl instance, and override all methods in DatagramSocket so that DatagramSocketImpl is never called.
In both cases, the default DatagramSocket implementation will not be created - and there will be no file descriptor leak.

This is unfortunately not possible with MulticastSocket: if you subclass MulticlassSocket, the default implementation will *always* be created, even if it's never used. The only solution to avoid that is currently to replace the default DatagramSocketImplFactory by calling the static DatagramSocket.setDatagramSocketImplFactory. We need a better solution.

The solution proposed in this RFE is to allow DatagramSocket to both send and receive multicast datagrams. An application that need to completely replace the default multicast implementation, and that cannot be easily updated to use DatagramChannel, can do so by subclassing DatagramSocket instead.
Comments
Changeset: 2c28e364 Author: Daniel Fuchs <dfuchs@openjdk.org> Date: 2021-02-08 12:55:00 +0000 URL: https://git.openjdk.java.net/jdk/commit/2c28e364
08-02-2021
The current investigation (thanks Alan) is to see if we can hoist the two args joinGroup/leaveGroup up from MulticastSocket to DatagramSocket. DatagramSocket can then be used directly to send (which it already can) and receive (which would be new) multicast packet. Some improvement to the API documentation of DatagramSocket and MulticastSocket could also be carried out along the way, in particular to show that the convenience getter/setter on MulticastSocket can be replaced by getOption/setOption. Some code example to show how DatagramSocket could be used directly to send and receive multicast datagrams will also be added. Further simplifications of the implementation would then become possible after/if we eventually remove the -Djdk.net.usePlainDatagramSocketImpl switch in a future release.
27-01-2021
It would be useful to get use-cases for extending DatagramSocket and MulticastSocket to see if it's worth doing anything. Testing? There may be projects with tests that mock these classes. If the mocked classes do not invoke close method in the super class then they will be a resource leak. Customization or decorating? A well behaved FooMulticastSocket that defines additional methods or override existing methods for instrumentation or other purposes should be okay. Alternative underlying implementation? The setDatagramSocketImplFactory method has existed since JDK 1.3 for those that want the JDK to use an alternative underlying implementation but not clear if it was ever used. DatagramSocketImpl is woefully underspecified and doing a real implementation requires access to the internals of FileDescriptor and DatagramPacket. If the DatagramSocketImpl mechanism were to go away then maybe a project will come out of the woodwork looking for an alternative. I see Daniel's suggestion to add new constructors but we probably should steer developers away from that, maybe to interfaces such ByteChannel and MulticastChannel instead, or new interfaces if there is a strong need.
17-01-2020