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