RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
michael.x.mcmahon at oracle.com
Tue Aug 6 17:18:39 UTC 2013
On 06/08/13 16:57, Alan Bateman wrote:
> On 06/08/2013 08:32, Chris Hegarty wrote:
>> This is a followup to the recent discussion on:
>> Two DatagramPacket constructors declare that they throw SocketException.
>> DatagramPacket(byte buf, int len, SocketAddress sa) throws
>> DatagramPacket(byte buf, int off, int len, SocketAddress sa)
>> throws SocketException
>> As it happens 'throws SE' was incorrectly added to these constructors
>> when introduced in 1.4. The original API specified that SE was thrown
>> when the given SocketAddress was not supported. That was later
>> changed to throw IAE, in 1.4.2. These constructor now can never throw
>> Removing 'throws SE' from the method declaration is a binary
>> compatible change, but not source compatible ( XXX is never thrown in
>> body of corresponding try statement ).
>> The conclusion of the discussion is that since these constructors are
>> not that widely used (the InetAddress+port variants are more
>> popular). Where they are, the affected code typically sends the
>> packet, which requires handling of IOException anyway.
>> A note will be added to the jdk8 release notes documenting this
> While it a source incompatible change, I think it's the right thing to
> The patch looks fine to me (if you want then the declaration will
> probably fit on one line now).
Late to this discussion ...
So, the extent of the source compatibility is that a possible user of
this class may have to
edit their calling code, when recompiling in JDK 8 to possibly remove a
block, which was dead code that was never being called? I guess that is
since it's not so likely to happen. But, if it does, it will probably
cause some confusion,
as developers won't be expecting it.
Documenting in release notes is okay too, but I suspect developers are
not likely to look there
at first anyway. Thinking aloud, it would be nice if some kind of
annotation could be associated
with the affected constructors such that a more meaningful/customized
could be emitted by javac. But, perhaps there aren't sufficient other
use cases to justify that.
More information about the core-libs-dev