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:
http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html
(cont'd)
http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html
Two DatagramPacket constructors declare that they throw SocketException.
DatagramPacket(byte[] buf, int len, SocketAddress sa) throws
SocketException
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
SE.
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
incompatibility.
While it a source incompatible change, I think it's the right thing to
do.
The patch looks fine to me (if you want then the declaration will
probably fit on one line now).
-Alan.
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
catch(SocketException)
block, which was dead code that was never being called? I guess that is
okay especially
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
error message
could be emitted by javac. But, perhaps there aren't sufficient other
use cases to justify that.
Michael.
