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 1273: > 1271: * @since 17 > 1272: */ > 1273: public void joinGroup(SocketAddress mcastaddr, NetworkInterface > netIf) What would you think about reducing the first sentence to "Join a multicast group". The reason is "at the specified interface" is a bit awkward in that it identifies the network by its network interface and that is hard to word in a readable-way. The second paragraph where it explains the two parameters is good so that helps the case for a simple first sentence. I think we need wording to make it clear joinGroup can be call several times to join several multicast groups. It can join the same group on several networks too. Another thing that is looks to be missing is the behavior when already a member of the group. We might have to tweak the wording for leaveGroup to make it clear how it behaves when invoked to leave a group that the socket didn't join. ------------- PR: https://git.openjdk.java.net/jdk/pull/2312
