Binary Compatibility - The Java Language Specification - page 361

Changing an instance method that is not declared final to be declared final may break com-
patibility with existing binaries that depend on the ability to override the method.
Example 13.4.17-1. Changing A Method To Be final
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();
t.out();
}
void out() { super.out(); }
}
This program produces the output:
out
Suppose that a new version of class Super is produced:
class Super { final void out() { System.out.println("!"); } }
If Super is recompiled but not Test , then running the new binary with the existing binary
of Test results in a VerifyError because the class Test improperly tries to override the in-
stance method out .
Changing a class ( static ) method that is not declared final to be declared final does not break
compatibility with existing binaries, because the method could not have been overridden.
13.4.18. native Methods
Adding or deleting a native modifier of a method does not break compatibility with pre-ex-
isting binaries.
The impact of changes to types on pre-existing native methods that are not recompiled is
beyond the scope of this specification and should be provided with the description of an im-
plementation. Implementations are encouraged, but not required, to implement native meth-
ods in a way that limits such impact.
13.4.19. static Methods
If a method that is not declared private is also declared static (that is, a class method) and is
changed to not be declared static (that is, to an instance method), or vice versa, then compat-
ibility with pre-existing binaries may be broken, resulting in a linkage time error, namely