分类： Java
2010-07-15 10:49:38
Hist:
1007015, draft
Here is a list of some important binary compatible changes that the Java programming language supports:
1) reimplementing existing methods, constructors, and initializers to improve performance.
2) changing mehtods or constructors to return values on inputs for which they previously either threw exceptions that normally should not occur or failed by going into an infinite loop or causing a deadlock.
3) adding new fields, methods, or constructors to an existing class or interface.
4) deleting private fields, methods, or constructors of a class.
5) when an entire package is updated, deleting default(package-only) access fields, methods, or constructors of classes and interfaces in the package.
6) reordering the fields, methods, or constructors in an existing type declaration.
7) moving a method upward in the class hierarchy.
8) reordering the list of direct superinterfaces of a class or interface.
9) inserting new class or interface types in the type hierarchy.
The Form of a Binary
The class file must have certain properties:
1) the class or interface must be named by its binary name, which must meet the following constraints:
a) the binary name of a top-level type is its canonical name.
b) the binary name of a member type consists of the binary name of its immediately enclosing type, followed by $, followed by the simple name of the member.
c) the binary name of a local class consists of the binary name of its immediately enclosing type, followed by $, followed by a non-empty sequence of digits, followed by the simple name of the local class.
d) the binary name of an anonymous class consists of the binary name of its immediately enclosing type, followed by $, followed by a non-empty sequence of digits.
e) the binary name of a type variable declared by a generic class or interface is the binary name of its immediately enclosing type, followed by $, followed by the simple name of the type variable.
f) the binary name of a type variable declared by a generic method or a generic constructor is the binary name of the type declaring the method, followed by $, followed by the descriptor of the method as defined in JVM, followed by $, followed by the simple name of the type variable.
2) a reference to another class or interface type must be symbolic, using the binary name of the type.
3) given a legal expression denoting a field access in a class C, referencing a non-constant field named f declared in a class or interface D, we define the qualifying type of the field reference as follows:
a) If the expression is of the form Primary.f then:
i. if the compile-time type of Primary is an intersection type V1&..&Vn, then the qualifying type of the reference is V1.
ii. otherwise, the compile-time type of Primary is the qualifying type of the reference.
b) if the expression is of the form super.f then the superclass of C is the qualifying type of the reference.
c) if the expression is of the form X.super.f then the superclass of X is the qualifying type of the reference.
d) if the reference is of the form X.f, where X denotes a class or interface, then the class or interface denoted by X is qualifying type of the reference.
e) if the expression is reference by a simple name, then if f is a memeber of the current class or interface, C, then let T be C. Otherwise, let T be the innermost lexically enclosing class of which f is a member. T is the qualifying type of the reference.
The reference of f must be compiled into a symbolic reference to the erasure of the qualifying type of the reference, plus the simple name of the field, f.
4) reference to fields that are constant variables are resolved at compile time to the constant value that is denoted.
5)
given a method invocation
expression in a class or interface C referencing a method named m declared in a
class or interface D, we define the qualifying type of
the method invocation as follows
If D is Object then the qualifying type of the expression is Object. Otherwise:
a) If the expression is of the form Primary.m then:
i. if the compile-time type of Primary is an intersection type V1&...&Vn, then the qualifying type of the method invocation is V1.
ii. otherwise, the compile-time of Primary is the qualifying type of the method invocation.
b) if the expression is of the form super.m then the superclass of C is the qualifying type of the method invocation.
c) if the expression is of the form X.super.m then the superclass of X is the qualifying type of the method invocation.
d) if the reference is of the form X.m, where X denotes a class or interface, then the class or interface denoted by X is the qualifying type of the method invocation.
e) If the method is reference by a simple name, then if m is a member of the current class or interface, C, let T be C. Otherwise, let T be the innermost lexically enclosing class of which m is a member. T is the qualifying type of the method invocation.
A reference to a method must be resolve at compile time to a symbolic reference to the erasure of the qualifying type of the invocation, plus the erasure of the signature of the method. The signature of a method must include all of the following:
a) the simple name of the method
b) the number of parameters to the method
c) a symbolic reference to the type of each parameter
6) given a class instance creation expression or a constructor invocation statement in a class or interface C referencing a constructor m declared in a class or interface D, we define the qualifying type of the constructor invocation as follows:
a) if the expression is of the form new D(...) or X.new D(...), then the qualifying type of the invocation is D.
b) if the expression is of the form new(...){...} or X.new D(...){...}, then the qualifying type of the expression is the compile-time type of the expression.
c) if the expression is of the form super(...) or Primary.super(...) then the qualifying type of the expression is the direct superclass of C
d) if the expression is of the form this(...), then the qualifying type of the expression is C
A reference to a constructor must be resolved at compile time to a symbolic reference to the erasure of the qualifying type of the invocation, plus the signature of the constructor.
7) any constructs introduced by the compiler that do not have a corresponding construct in the src code must be marked as synthetic, except for default constructors and the class initialization method.
A binary representation for a class or interface must also contain all of the following:
1) if it is a class and is not class Object, then a symbolic reference to the erasure of the direct superclass of this class.
2) a symbolic reference to the erasure of each direct superinterface, if any
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, its erased signature and return type, as described above
6) the code needed to implement the class or interface:
a) for an instance, code for the field initializers
b) 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.
8) every member type must have sufficient information to recover its source level access 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 methods, constructors and static or instance initializers.
What Binary Compatibility Is and Is Not
A change to a type is binary compatible with preexisting binaries if preexisting binaries that previously linked without error will continue to link without error.
The Java programming language is designed to prevent additions to contracts and accidental name collisions from breaking binary compatibility.
Evolution of Packages
A new top-level class or interface type may be added to a package without breaking compatibility with pre-existing binaries, provided the new type does not reuse a name previously given to an unrelated type.
Evolution of Classes
abstract Classes
a class that was not abstract is changed to be declared abstract, it is not recommended.
final Classes
a class that was not final is changed to be declared final, it is not recommended.
public Classes
Superclasses and Superinterfaces
Class Formal Type Parameters
Class Body and Member Declarations
Access to Members and Constructors
Changing the declared access of a member or constructor to permit less access may break compatibility with pre-existing binaries, causing a linkage error to be thrown when these binaries are resolved.
Field Declarations
Adding a field to a class may break compatibility with pre-existing binaries that are not recompiled.
final Fields and Constants
not final => final, it can break compatibility with pre-existing binaries.
static Fields
transient Fields
Method and Constructor Declarations
Method and Constructor Formal Type Parameters
Method and Constructor Parameters
Method Result Type
abstract method
final Method
native Method
Adding or deleting a native modifier of a method does not break compatibility with pre-existing binaries.
static Methods
synchronized Methods
Method and Constructor Throws
Method and Constructor Body
Method and Constructor Overloading
Method Overriding
Static Initializers
Evolution of Enums
Evolution of Interfaces
public interfaces, superinterfaces, the interface methods, interface formal type parameters, field declarations, abstract method declarations, evolution of annotation types
REF
1. JLS 3nd
2.
JVM 2nd
