Binary Compatibility - The Java Language Specification - page 360

For purposes of binary compatibility, adding or removing a method or constructor m whose
return type involves type variables (§ 4.4 ) or parameterized types (§ 4.5 ) is equivalent to the
addition (respectively, removal) of the an otherwise equivalent method whose return type
is the erasure (§ 4.6 ) of the return type of m .
13.4.16. abstract Methods
Changing a method that is declared abstract to no longer be declared abstract does not break
compatibility with pre-existing binaries.
Changing a method that is not declared abstract to be declared abstract will break compatib-
ility with pre-existing binaries that previously invoked the method, causing an AbstractMeth-
odError .
Example 13.4.16-1. Changing A Method To Be abstract
Click here to view code image
class Super { void out() { System.out.println("Out"); } }
class Test extends Super {
public static void main(String[] args) {
Test t = new Test();
System.out.println("Way ");
t.out();
}
}
This program produces the output:
Way
Out
Suppose that a new version of class Super is produced:
abstract class Super {
abstract void out();
}
If Super is recompiled but not Test , then running the new binary with the existing binary
of Test results in an AbstractMethodError , because class Test has no implementation of the
method out , and is therefore is (or should be) abstract .
13.4.17. final Methods
Changing a method that is declared final to no longer be declared final does not break com-
patibility with pre-existing binaries.