The longstanding behavior of DatagramSocket::receive is that it does
not perform a security manager check when connected ( which is similar
to DatagramChannel ). The security manager check is performed during
connect.

The specification for DatagramSocket::receive incorrectly implies that
the security manager check is always performed. Or at best, it is
ambiguous about the connected behavior. From DatagramSocket::receive -

   * If there is a security manager, a packet cannot be received if the
   * security manager's {@code checkAccept} method does not allow it.

DatagramSocket::receive should have wording similar to its NIO
counterpart, DatagramChannel, e.g.

   * <p> This method performs exactly the same security checks as the {@link
   * java.net.DatagramSocket#receive receive} method of the {@link
   * java.net.DatagramSocket} class.  That is, if the socket is not connected
   * to a specific remote address and a security manager has been installed
   * then for each datagram received this method verifies that the source's
   * address and port number are permitted by the security manager's {@link
   * java.lang.SecurityManager#checkAccept checkAccept} method.  The overhead
   * of this security check can be avoided by first connecting the socket via
   * the {@link #connect connect} method.

In fact, the discrepancy can be seen from the above two snippets. They
somewhat contradict each other.

---

A connected datagram socket /channel is a capability. It would be good
if the API noted this.