RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException

[Chris Hegarty]

> On 18 Dec 2019, at 11:09, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 18/12/2019 10:55, Daniel Fuchs wrote:
>> We already have two implementations of DatagramSocket: one is the plain
>> DatagramSocket, the other is the DatagramSocket adapter created by
>> DatagramChannel::socket.
>> 
>> Even without preparing for DatagramSocket reimplementation this
>> is a step forward in homogenizing these two implementations in
>> the spec.

Yeah, and we have done similar in the past.

>> Oh - I see DatagramChannel::socket adapter also behaves like this
>> and explicitly ignores the ClosedChannelException.
>> 
>> Is there any reason for letting connect go through if the socket
>> is closed? I mean - should we change the spec/behavior of
>> DatagramSocket (and the adapter) to throw in that case?
> Changing DatagramSocket connect to throw an exception when the socket is closed would be an incompatible

True, such a change, if it were to be proposed, would require a CSR.

> change so I think this is a case where the spec will just need to align with long standing behavior.

Not withstanding the various different post-close behaviour of the
methods of DatagramSocket ( throw IOException, silently ignore, return a
default value, return last known value ), I think that it would be best
to clarify the specification with the existing, long standing,
behaviour; "Invoking this method on a closed socket has *effectively* no
effect." - or something like that.

It would be good to clarify that now, as part of this change, since it’s
an obvious question that arises now that UncheckedIOException is being
added.

-Chris.