RFR: 8319417: (dc) DatagramChannel.connect undocumented behavior [v2]

[Mark Sheppard]

On Tue, 28 Nov 2023 18:59:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Returns: the local address to which the socket is bound, null if the socket is closed, or an InetAddress representing [wildcard](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/InetAddress.html#isAnyLocalAddress()) address if either the socket is not bound, or the security manager checkConnect method does not allow the operation
> 
> DatagramSocket.getLocalAddress dates from JDK 1.1 and its odd behavior couldn't be changed for compatibility reasons. The newer DatagramSocket.getLocalSocketAddress is specified to return null when not bound.

Hmm! sound like a bit of a fudge, and doesn't really make sense, as DatagramSocket and DatagramChannel essentially delegate to the same underlying implementation, which in turn delgates to the same underlying native implementation for which the OS will have a strong influence on the semantics offered at the higher level. 
Thus, in the case of an unbounded lower level socket, upon which a send (or connect) has been invoked, a subsequent getsockname would return whatever the OS has implicitly bound to the socket in terms of address and port. 
Thus, a similar scenario would be expected at the Java API level, and should result in the getLocalAddress method exhibiting the same semantics, returning  the same InetAddress for all specified conditions, irrespective of which API is called.
If both APIs delegate to the same underlying implementation, then it is reasonable to expect that they both exhibit a consistent samantics in their APIs. This is  especially true as DatagramChannel  exposes an associated DatagramSocket, which based your statement  will allow  a duality of behaviour to exist.
Regardless of compatibility, this is reasonably conceived as broken behaviour.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16635#issuecomment-1830638977