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






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

java hosting

 

Our partners: PHP: Hypertext Preprocessor Best Web Hosting Java Web Hosting Inexpensive Web Hosting  Jsp Web Hosting

Cheapest Web Hosting Jsp Hosting Cheap Hosting

Visionwebhosting.net Business web hosting division of Web Design Plus. All rights reserved