Java Reference
In-Depth Information
throwAorB();
} catch(ExceptionA | ExceptionB e) {
...
}
where
ExceptionA
and
ExceptionB
do not have a subclass/superclass relationship when
the client is compiled, it is binary compatible with respect to the client for
ExceptionA
and
ExceptionB
to have such a relationship when the client is executed.
This is analogous to other situations where a class transformation that is binary com-
patible for a client might not be source compatible for the same client.
13.4.5. Class Type Parameters
Adding or removing a type parameter of a class does not, in itself, have any implications
for binary compatibility.
If such a type parameter is used in the type of a field or method, that may have the normal
implications of changing the aforementioned type.
Renaming a type parameter of a class has no effect with respect to pre-existing binaries.
Changing the first bound of a type parameter of a class may change the erasure (§
4.6
) of
any member that uses that type parameter in its own type, and this may affect binary com-
patibility. The change of such a bound is analogous to the change of the first bound of a
Changing any other bound has no effect on binary compatibility.
13.4.6. Class Body and Member Declarations
No incompatibility with pre-existing binaries is caused by adding an instance (respectively
static
) member that has the same name and accessibility (for fields), or same name and ac-
cessibility and signature and return type (for methods), as an instance (respectively
static
)
member of a superclass or subclass. No error occurs even if the set of classes being linked
would encounter a compile-time error.
Deleting a class member or constructor that is not declared
private
may cause a linkage error
if the member or constructor is used by a pre-existing binary.
Example 13.4.6-1. Changing A Class Body
class Hyper {
