Java Reference
In-Depth Information
Chapter 13. Binary Compatibility
Development tools for the Java programming language should support automatic recompil-
ation as necessary whenever source code is available. Particular implementations may also
store the source and binary of types in a versioning database and implement a
ClassLoader
that uses integrity mechanisms of the database to prevent linkage errors by providing binary-
compatible versions of types to clients.
Developers of packages and classes that are to be widely distributed face a different set of
problems. In the Internet, which is our favorite example of a widely distributed system, it is
often impractical or impossible to automatically recompile the pre-existing binaries that dir-
ectly or indirectly depend on a type that is to be changed. Instead, this specification defines
a set of changes that developers are permitted to make to a package or to a class or interface
type while preserving (not breaking) compatibility with pre-existing binaries.
Within the framework of
Release-to-Release Binary Compatibility in SOM
(Forman, Con-
ner, Danforth, and Raper,
Proceedings of OOPSLA '95
), Java programming language binar-
ies are binary compatible under all relevant transformations that the authors identify (with
some caveats with respect to the addition of instance variables). Using their scheme, here
is a list of some important binary compatible changes that the Java programming language
supports:
• Reimplementing existing methods, constructors, and initializers to improve per-
formance.
• Changing methods or constructors to return values on inputs for which they previ-
ously either threw exceptions that normally should not occur or failed by going into
an infinite loop or causing a deadlock.
• Adding new fields, methods, or constructors to an existing class or interface.
• Deleting
private
fields, methods, or constructors of a class.
• When an entire package is updated, deleting default (package-only) access fields,
methods, or constructors of classes and interfaces in the package.
• Reordering the fields, methods, or constructors in an existing type declaration.
• Moving a method upward in the class hierarchy.
• Reordering the list of direct superinterfaces of a class or interface.
• Inserting new class or interface types in the type hierarchy.
