CloneNotSupportedException should extends RuntimeException not Exception
Joe Darcy
joe.darcy at oracle.com
Fri Nov 2 22:44:05 UTC 2012
On 10/15/2012 03:56 AM, Alan Bateman wrote:
> On 15/10/2012 11:28, Joel Borggrén-Franck wrote:
>> On 10/15/2012 12:34 AM, David Holmes wrote:
>> > Remi,
>> >
>> > This ship has sailed you can't recall it.
>> CloneNotSupportedException > is a checked exception and needs to
>> remain so for source and binary
>> > compatibility.
>> >
>>
>> I see how this is source incompatible and also behaviorally
>> incompatible in a few cases, but how is this binary incompatible?
> I think you're right as there wouldn't be a linkage error.
>
> his thread reminds of Joe Darcy's classic blog on compatibility kinds:
>
> https://blogs.oracle.com/darcy/entry/kinds_of_compatibility
>
Hello,
Catching up on email, changing the supertype of an exception from
Exception to RuntimeException exception is *binary* compatible under the
rules for superclasses and interfaces evolution given in the JLS:
"Changing the direct superclass or the set of direct superinterfaces of
a class type will not break compatibility with pre-existing binaries,
provided that the total set of superclasses or superinterfaces,
respectively, of the class type loses no members."
http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.4
Since the subtype (RuntimeException) has all the members of its parent
(Exception), and also the same set of constructor signatures, this
change is binary compatible and will *not* cause a linkage error at
runtime (which is the definition of binary compatible).
As Brian pointed out, there is a small risk of source and behavioural
compatibility change is a try block had both catch clauses for
CloneNotSupportedException and RuntimeException. That in and of itself
doesn't rule out such a change since our general evolution policy for
the JDK is:
> 1. Don't break binary compatibility (as defined in the Java
> Language Specification).
>
> 2. Avoid introducing source incompatibilities.
>
> 3. Manage behavioral compatibility changes.
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.775.html#general_evolution_policy
In some lesser-used corners of the platform, we've made just this sort
of change with exception superclasses, in full awareness of the
potential issues:
6519115 MirroredTypeException thrown but should be
MirroredTypesException
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519115
http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/852d8bb356bc
However, given the prevalence of CloneNotSupportedException, I don't
think making it an unchecked exception after it was a checked exception
is appropriate.
-Joe
More information about the core-libs-dev
mailing list