This is my notes from a quick proof-of-concept to show how DatagramSocket and
MulticastSocket could be implemented with DatagramChannel and its socket adatptor,
and without a DatagramSocketImpl implementation.

Run with -Djdk.net.usePlainDatagramSocketImpl=true to use the legacy DatagramSocket
and PlainDatagramSocketImpl.

The prototype assumes the macOS disconnect bug FB7330899 is resolved or a workaround
to re-create the underlying socket (JDK-8231259).

Missing
=======

- The prototype does not include the changes to DatagramChannel to support the
creation of a channel that doesn't respond to Thread.interrupt. This issue needs to
be explored for the socket adaptor too.


Behavior differences
====================

- Legacy DatagramSocket connect falls back to emulation when the underlying
connect fails, e.g. connect to a non-routable address.

- DatagramChannel discards all datagrams in the socket read buffer when connecting.

- DatagramSocket::supportedOptions has been changed to include socket options
applicable to sending multicast datagrams (as DatagramSocket can be used to send
both unicast and multicast datagrams). 

- DatagramSocket.send throws IllegalArgumentException if the packet doesn't have
a socket address and the socket is not connected. Legacy DatagramSocket throws
an accidental NullPointerException. JDK-8233141.

- getOption(IP_MULTICAST_IF) returns null when the interface for outgoing multicast
datagrams has not been set. Legacy DatagramSocket incorrectly returns a useless
interface. JDK-8233307.

- getOption(IP_MULTICAST_LOOP) has been changed to return true if the loopback of
multicast datagrams is enabled (as specified in StandardSocketOptions). JDK-8233296.

- The ordering that parameters are checked, the security manager check, and
the check for a closed socket differ, e.g. joinGroup(null) when the socket is closed
will throw SocketException in the legacy implementation, NPE in the prototype.