Maybe we can retain existing behaviour, while implicitly specifying the IAE?
@@ -311,16 +312,21 @@
setAddress(addr.getAddress());
setPort(addr.getPort());
}
/**
* Gets the SocketAddress (usually IP address + port number) of the remote
* host that this packet is being sent to or is coming from.
*
+ * <p> This method is the equivalent to invoking:
+ * <pre> {@code
+ * new InetSocketAddress(getAddress(), getPort())
+ * }</pre>
+ *
* @return the {@code SocketAddress}
* @since 1.4
* @see #setSocketAddress
*/
public synchronized SocketAddress getSocketAddress() {
return new InetSocketAddress(getAddress(), getPort());
}
This approach leans on the behaviour of other existing methods,
and show up further gaps in their specifications ( which should
be resolved anyway ) [*]
[*]
/**
* Returns the IP address of the machine to which this datagram is being
* sent or from which the datagram was received.
*
* @return the IP address of the machine to which this datagram is being
- * sent or from which the datagram was received.
+ * sent or from which the datagram was received; may be null
* @see java.net.InetAddress
* @see #setAddress(java.net.InetAddress)
*/
public synchronized InetAddress getAddress() {
return address;
}
/**
* Returns the port number on the remote host to which this datagram is
* being sent or from which the datagram was received.
*
* @return the port number on the remote host to which this datagram is
- * being sent or from which the datagram was received.
+ * being sent or from which the datagram was received; {@code -1}
+ * if not set
* @see #setPort(int)
*/
public synchronized int getPort() {
return port;
}
/**
* Returns the data buffer. The data received or the data to be sent
-Chris.
> On 24 Jan 2020, at 12:26, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> On 24/01/2020 11:49, Daniel Fuchs wrote:
>>
>> If I'm not mistaken, one side effect here is that this allows
>> the DatagramSocketAdaptor to throw IllegalArgumentException when
>> it is not connected and passed a DatagramPacket in which the port
>> as not been set.
> Yes, that's the outlier I mentioned in the reply (that usage should probably
> be changed anyway as the send shouldn't be create a SocketAddress).
>
>> :
>>
>> I wonder if it might be more prudent to just keep and document
>> the current behavior.
> Maybe. We normally default to specifying the long standing behavior but there
> are cases where the risk of fixing an issue is very low, e.g
> DatagramSocket.send was changed recently to throw IAE for a case that was
> previously unspecified and where the implementation threw an accidental NPE.
> -Alan.
