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

[Alan Bateman]

On Tue, 28 Nov 2023 20:06:15 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> 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.

DatagramSocket::getLocalAddress dates from JDK 1.0 and originally specified/implemented to return an InetAddress. The support for unbound sockets was added in JDK 1.4 (2004) and it would have been an incompatible change to change this method to return null, hence the current spec. I agree it's an odd API for this case but changing it now after all this time would be an incompatible change.

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

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