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