On Fri, 29 Jan 2021 18:59:04 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> DatagramSocket has a DatagramSocket.setDatagramSocketImplFactory method that >> allows to globally replace the default DatagramSocket/MulticastSocket >> implementation provided by the JDK. This was provided as a way in early JDK >> releases to replace the system wide implementation. It has been mostly >> obsolete since Java 1.4. A DatagramSocket can be created to use a custom >> implementation by extending DatagramSocket and using the protected >> constructor that takes the impl as a parameter. However, MulticastSocket >> doesn't provide such a constructor. >> >> Though DatagramSocket can be subclassed to provide a custom implementation, >> MulticastSocket, if subclassed, will still create its default >> implementation, even when all methods of MulticastSocket are overridden in >> order not to use it. This will create a file descriptor / socket leak. >> >> 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. DatagramSocket has always had the ability >> to send multicast packets. In Java 15, DatagramSocket has been improved to >> support getting/setting multicast options. This change proposes to move >> `joinGroup(SocketAddress, NetworkInterface)` and `leaveGroup(SocketAddress, >> NetworkInterface)` up from MulticastSocket into DatagramSocket. >> >> An application that needs to completely replace the default multicast >> implementation, and that cannot be easily updated to use DatagramChannel, >> can do so by subclassing DatagramSocket instead. >> >> In addition, this change improves the documentation of DatagramSocket and >> MulticastSocket to show how convenience getters/setters map to >> StandardSocketOptions, and adds an `@apiNote` to show how DatagramSocket can >> be used for multicasting. >> >> Specdiff can be seen here: >> http://cr.openjdk.java.net/~dfuchs/ds-ms-8237352-specdiff.07/overview-summary.html >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8260667 > > Daniel Fuchs has updated the pull request incrementally with one additional > commit since the last revision: > > Fixup @bug in the tests src/java.base/share/classes/java/net/DatagramSocket.java line 163: > 161: * > 162: * <p> An instance of {@code DatagramSocket} can be used to send or > 163: * receive multicast datagram packets. It is no necessary to join a > multicast Typo, should be "not necessary" src/java.base/share/classes/java/net/DatagramSocket.java line 223: > 221: * to the address type of the multicast groups that the {@code > DatagramSocket} > 222: * will join. This is similar to a {@code DatagramChannel} that > would be created > 223: * using {@link DatagramChannel#open()}. I think this paragraph might be confusing to readers. I think you just want to say that DatagramSocket does not support a way to specify the PF when creating the socket. Consequently the underlying socket may not correspond to the multicast groups that the DatagramSocket attempts to join. ------------- PR: https://git.openjdk.java.net/jdk/pull/2312
