On Tue, 28 Nov 2023 18:59:15 GMT, Alan Bateman <[email protected]> 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
