13.1

The Form of a Java Binary

BINARY COMPATIBILITY

Moving a method upward in the class hierarchy, provided a forwarding

method is left in its place.

Reordering the list of direct superinterfaces of a class or interface.

Inserting new class or interface types in the type hierarchy.

This chapter specifies minimum standards for binary compatibility guaranteed

by all Java implementations. Java guarantees compatibility when binaries of

classes and interfaces are mixed that are not known to be from compatible

sources, but whose sources have been modified in the compatible ways described

here.

We encourage Java development systems to provide facilities that alert devel 

opers to the impact of changes on pre existing binaries that cannot be recompiled.

This chapter first specifies some properties that any Java binary format must

have ( 13.1). It next defines binary compatibility, explaining what it is and what it

is not ( 13.2). It finally enumerates a large set of possible changes to packages

( 13.3), classes ( 13.4) and interfaces ( 13.5), specifying which changes are

guaranteed to preserve binary compatibility and which are not.

13.1   The Form of a Java Binary

While many Java binary files are likely to be in exactly the

class

 file format spec 

ified by the

The Java Virtual Machine Specification

, this specification does not

mandate the use of any specific binary file format. Rather, it specifies properties

that any binary format for compiled types must obey. A number of these proper 

ties are specifically chosen to support source code transformations that preserve

binary compatibility.

The requirements are:

Binary formats for Java programs must be defined and processed to respect

the specifications of loading ( 12.2), linking ( 12.3) and initialization ( 12.4)

of class and interface types.

A reference to another class or interface type must be symbolic, using the

fully qualified name of the type as determined at compile time.

A reference to a field of another class or interface must be resolved at compile

time to a symbolic reference to the class or interface in which the field is

declared, plus the simple name of the field. (Including the exact class or inter 

face in which the field is declared makes the binaries more robust, since add 

ing another field with the same name, even in a subclass, cannot cause

238