Java Reference
In-Depth Information
The Java programming language is designed to prevent additions to contracts and accident-
al name collisions from breaking binary compatibility. Specifically, addition of more meth-
ods overloading a particular method name does not break compatibility with pre-existing
binaries. The method signature that the pre-existing binary will use for method lookup is
If the Java programming language had been designed so that the particular method
to be executed was chosen at run time, then such an ambiguity might be detected at
run time. Such a rule would imply that adding an additional overloaded method so as
to make ambiguity possible at a call site could break compatibility with an unknown
number of pre-existing binaries. See §
13.4.23
for more discussion.
Binary compatibility is not the same as source compatibility. In particular, the example in
§
13.4.6
shows that a set of compatible binaries can be produced from sources that will
not compile all together. This example is typical: a new declaration is added, changing the
meaning of a name in an unchanged part of the source code, while the pre-existing binary
for that unchanged part of the source code retains the fully-qualified, previous meaning of
the name. Producing a consistent set of source code requires providing a qualified name or
field access expression corresponding to the previous meaning.
13.3. Evolution of Packages
A new top level class or interface type may be added to a package without breaking com-
patibility with pre-existing binaries, provided the new type does not reuse a name previ-
ously given to an unrelated type.
If a new type reuses a name previously given to an unrelated type, then a conflict may res-
ult, since binaries for both types could not be loaded by the same class loader.
Changes in top level class and interface types that are not
public
and that are not a superclass
or superinterface, respectively, of a
public
type, affect only types within the package in
which they are declared. Such types may be deleted or otherwise changed, even if incom-
patibilities are otherwise described here, provided that the affected binaries of that package
are updated together.
13.4. Evolution of Classes
This section describes the effects of changes to the declaration of a class and its members
and constructors on pre-existing binaries.
