BINARY COMPATIBILITY

final

Methods

13.4.16

abstract class Super {

abstract void out();

}

If

Super

 is recompiled but not

Test

, then running the new binary with the exist 

ing binary of

Test

 results in a

AbstractMethodError

, because class

Test

 has no

implementation of the method

out

, and is therefore is (or should be) abstract. (An

early version of Java incorrectly produced the output:

Way

before encountering an

AbstractMethodError

 while invoking the method

out

,

incorrectly allowing the class

Test

 to be prepared even though it has an

abstract

method and is not declared

abstract

.)

13.4.16

final

Methods

Changing an instance method that is not

final

 to be

final

 may break compati 

bility with existing binaries that depend on the ability to override the method. If

the test program:

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(); }

}

is compiled and executed, it 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 exist 

ing binary of

Test

 results in a

VerifyError

 because the class

Test

 improperly

tries to override the instance method

out

.

Changing a class (

static

) method that is not

final

 to be

final

 does not

break compatibility with existing binaries, because the class of the actual method

to be invoked is resolved at compile time.

255