On 11/02/2012 11:44 PM, Joe Darcy wrote:
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.
We also add a common super types (ReflectiveOperationException) of all
exceptions thrown by reflection code.
But in that case, because the exception ReflectiveOperationException
didn't exist before, there was no problem of compatibility.
BTW, I've found a way to solve the problem of
CloneNotSupportedException, I don't say that we should do that,
The idea just to explicitly change the JLS to say that
CloneNotSupportedException is now unchecked.
In that case, this is a binary compatible change and there is no
behavioural incompatibility.
-Joe
Rémi
