> On 18 Dec 2019, at 11:09, Alan Bateman <alan.bate...@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.
