EXPRESSIONS

Compile Time Step 2: Determine Method Signature

15.11.2

If the application programmer then runs the old binary file for

Test

 with the

new binary file for

ColoredPoint

, the output is still:

cp: (3,3,red)

because the old binary file for

Test

 still has the descriptor  one parameter, whose

type is

Point

;

void

  associated with the method call

cp.adopt(cp2)

. If the

source code for

Test

 is recompiled, the compiler will then discover that there are

now two applicable

adopt

 methods, and that the signature for the more specific

one is  one parameter, whose type is

ColoredPoint

;

void

 ; running the program

will then produce the desired output:

cp: (3,3,green)

With forethought about such problems, the maintainer of the

points

 package

could fix the

ColoredPoint

 class to work with both newly compiled and old

code, by adding defensive code to the old

adopt

 method for the sake of old code

that still invokes it on

ColoredPoint

 arguments:

public void adopt(Point p) {

if (p instanceof ColoredPoint)

color = ((ColoredPoint)p).color;

x = p.x; y = p.y;

}

A similar consideration applies if a method is to be moved from a class to a

superclass. In this case a forwarding method can be left behind for the sake of old

code. The maintainer of the

points

 package might choose to move the

adopt

method that takes a

Point

 argument up to class

Point

, so that all

Point

 objects

may enjoy the

adopt

 functionality. To avoid compatibility problems with old

binary code, the maintainer should leave a forwarding method behind in class

ColoredPoint

:

public void adopt(Point p) {

if (p instanceof ColoredPoint)

color = ((ColoredPoint)p).color;

super.adopt(p);

}

Ideally, Java code should be recompiled whenever code that it depends on is

changed. However, in an environment where different Java classes are maintained

by different organizations, this is not always feasible. Defensive programming

with careful attention to the problems of class evolution can make upgraded code

much more robust. See  13 for a detailed discussion of binary compatibility and

type evolution.

331