RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'
Alan Bateman
Alan.Bateman at oracle.com
Sat Apr 11 07:54:08 UTC 2020
On 10/04/2020 22:53, mark sheppard wrote:
>
> Hi Patrick,
> if I understand the change correctly, you wish to eliminate the
> IllegalArgumentException and return an InetSocketAddress
> based on the current set values for address and port.
Yes, it is surprising to have it throw an undocumented IAE as there are
no arguments. It is compounded by a long standing undocumented behavior
to initialize the port to -1. Navigating through historical mistakes is
always tricky. Patrick, Daniel, and I discussed several options around
this and I think Patrick's proposal is the best of a bad hand in that it
minimizes the compatibility impact and consistency issues that rise when
changing old APIs. Changing getSocketAddress() to return null would be a
hazard. IllegalStateException should have been looked at in 1.4 but
awkward/too-late to change it now. One other thing is that this change
connects to possible future changes to DatagramSocket and
DatagramChannel to allow sending (and maybe connect) to the wildcard
address. Socket and SocketChannel have always converted attempts to
connect to the wildcard address to an attempt to connect to the host or
loopback address. This makes it easy for newbies and tests to connect to
a listener's socket address without needing to special case the wildcard
address. An equivalent for Datagram is something that I think Daniel and
Patrick are thinking about.
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200411/5d6f9995/attachment-0001.htm>
More information about the net-dev
mailing list