BINARY COMPATIBILITY

Evolution of Packages

13.3

Introducing a new field with the same name as an existing field, in a subclass

of the class containing the existing field declaration, does not break compati 

bility with preexisting binaries. See the example at the beginning of  13.4.5.

Addition of more methods overloading a particular method name does not

break compatibility with preexisting binaries. The method signature that the

preexisting binary will use for method lookup is chosen by Java's method

overload resolution algorithm at compile time ( 15.11.2). (If Java 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 became possible could break compatibility with an

unknown number of preexisting binaries. See  13.4.22 for more discussion.)

Binary compatibility is not the same as source compatibility. In particular, the

example in  13.4.5 shows that a set of compatible binaries can be produced from

sources that will not compile all together. This example is typical: a new declara 

tion is added, changing the meaning of a name in an unchanged part of the source

code, while the preexisting 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.

We hope to make some improvements to future versions of Java to better sup 

port both source and binary compatible evolution of types. In particular, we are

considering a mechanism to allow a class to implement two interfaces that have

methods with the same signature but are to be considered different or have differ 

ent return types. We welcome suggestions and proposals that would help us to

make additional improvements, either in managing name and signature conflicts

or other sources of incompatibility.

13.3   Evolution of Packages

A new 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

previously given to an unrelated type. If a new type reuses a name previously

given to an unrelated type, then a conflict may result, since binaries for both types

could not be loaded by the same class loader.

Changes in class and interface types that are not

public

 and that are not a

superclass or superinterface, respectively, of a

public

 type, affect only types

241