Java Reference
In-Depth Information
3. A specification of each field declared in the class or interface, given as the simple
name of the field and a symbolic reference to the erasure of the type of the field.
4. If it is a class, then the erased signature of each constructor, as described above.
5. For each method declared in the class or interface (excluding, for an interface, its
implicitly declared methods (§ 9.2 ) ), its erased signature and return type, as de-
scribed above.
6. The code needed to implement the class or interface:
• For an interface, code for the field initializers
• For a class, code for the field initializers, the instance and static initializers, and
the implementation of each method or constructor
7. Every type must contain sufficient information to recover its canonical name
6.7 ) .
8. Every member type must have sufficient information to recover its source level ac-
cess modifier.
9. Every nested class must have a symbolic reference to its immediately enclosing
class.
10. Every class that contains a nested class must contain symbolic references to all of
its member classes, and to all local and anonymous classes that appear in its meth-
ods, constructors, and static or instance initializers.
The following sections discuss changes that may be made to class and interface type de-
clarations without breaking compatibility with pre-existing binaries. Under the translation
requirements given above, the Java Virtual Machine and its class file format support these
changes. Any other valid binary format, such as a compressed or encrypted representation
that is mapped back into class files by a class loader under the above requirements, will ne-
cessarily support these changes as well.
13.2. What Binary Compatibility Is and Is Not
A change to a type is binary compatible with (equivalently, does not break binary com-
patibility with) pre-existing binaries if pre-existing binaries that previously linked without
error will continue to link without error.
Binaries are compiled to rely on the accessible members and constructors of other classes
and interfaces. To preserve binary compatibility, a class or interface should treat its access-
ible members and constructors, their existence and behavior, as a contract with its users.
Search WWH ::




Custom Search