Thinking in Java, 3rd ed. Revision 4.0

Music.java might seem strange to you. Why should anyone intentionally forget the type of an object? This is what happens when you upcast, and it seems like it could be much more straightforward if tune( ) simply takes a Wind reference as its argument. This brings up an essential point: If you did that, you'd need to write a new tune( ) for every type of Instrument in your system. Suppose we follow this reasoning and add Stringed and Brass instruments:

//: c07:music:Music2.java
// Overloading instead of upcasting.
package c07.music;
import com.bruceeckel.simpletest.*;
 
class Stringed extends Instrument {
	public void play(Note n) {
		System.out.println("Stringed.play() " + n);
	}
}
 
class Brass extends Instrument {
	public void play(Note n) {
		System.out.println("Brass.play() " + n);
	}
}
 
public class Music2 {
	private static Test monitor = new Test();
	public static void tune(Wind i) {
		i.play(Note.MIDDLE_C);
	}
	public static void tune(Stringed i) {
		i.play(Note.MIDDLE_C);
	}
	public static void tune(Brass i) {
		i.play(Note.MIDDLE_C);
	}
	public static void main(String[] args) {
		Wind flute = new Wind();
		Stringed violin = new Stringed();
		Brass frenchHorn = new Brass();
		tune(flute); // No upcasting
		tune(violin);
		tune(frenchHorn);
		monitor.expect(new String[] {
			"Wind.play() Middle C",
			"Stringed.play() Middle C",
			"Brass.play() Middle C"
		});
	}
} ///:~

This works, but there's a major drawback: you must write type-specific methods for each new Instrument class you add. This means more programming in the first place, but it also means that if you want to add a new method like tune( ) or a new type of Instrument, you've got a lot of work to do. Add the fact that the compiler won't give you any error messages if you forget to overload one of your methods and the whole process of working with types becomes unmanageable.

Wouldn't it be much nicer if you could just write a single method that takes the base class as its argument, and not any of the specific derived classes? That is, wouldn't it be nice if you could forget that there are derived classes, and write your code to talk only to the base class?

That's exactly what polymorphism allows you to do. However, most programmers who come from a procedural programming background have a bit of trouble with the way polymorphism works.

Connecting a method call to a method body is called binding. When binding is performed before the program is run (by the compiler and linker, if there is one), it's called early binding. You might not have heard the term before because it has never been an option with procedural languages. C compilers have only one kind of method call, and that's early binding.

The confusing part of the preceding program revolves around early binding, because the compiler cannot know the correct method to call when it has only an Instrument reference.

The solution is called late binding, which means that the binding occurs at run time, based on the type of object. Late binding is also called dynamic binding or run-time binding. When a language implements late binding, there must be some mechanism to determine the type of the object at run time and to call the appropriate method. That is, the compiler still doesn't know the object type, but the method-call mechanism finds out and calls the correct method body. The late-binding mechanism varies from language to language, but you can imagine that some sort of type information must be installed in the objects.

All method binding in Java uses late binding unless the method is static or final (private methods are implicitly final). This means that ordinarily you don't need to make any decisions about whether late binding will occur-it happens automatically.

Why would you declare a method final? As noted in the last chapter, it prevents anyone from overriding that method. Perhaps more important, it effectively "turns off" dynamic binding, or rather it tells the compiler that dynamic binding isn't necessary. This allows the compiler to generate slightly more efficient code for final method calls. However, in most cases it won't make any overall performance difference in your program, so it's best to only use final as a design decision, and not as an attempt to improve performance.

Once you know that all method binding in Java happens polymorphically via late binding, you can write your code to talk to the base class and know that all the derived-class cases will work correctly using the same code. Or to put it another way, you "send a message to an object and let the object figure out the right thing to do."

The classic example in OOP is the "shape" example. This is commonly used because it is easy to visualize, but unfortunately it can confuse novice programmers into thinking that OOP is just for graphics programming, which is of course not the case.

The shape example has a base class called Shape and various derived types: Circle, Square, Triangle, etc. The reason the example works so well is that it's easy to say "a circle is a type of shape" and be understood.The inheritance diagram shows the relationships:

The upcast could occur in a statement as simple as:

Shape s = new Circle();

Here, a Circle object is created, and the resulting reference is immediately assigned to a Shape, which would seem to be an error (assigning one type to another); and yet it's fine because a Circle is a Shape by inheritance. So the compiler agrees with the statement and doesn't issue an error message.

Suppose you call one of the base-class methods (that have been overridden in the derived classes):

s.draw();

Again, you might expect that Shape's draw( ) is called because this is, after all, a Shape reference-so how could the compiler know to do anything else? And yet the proper Circle.draw( ) is called because of late binding (polymorphism).

The following example puts it a slightly different way:

//: c07:Shapes.java
// Polymorphism in Java.
import com.bruceeckel.simpletest.*;
import java.util.*;
 
class Shape {
	void draw() {}
	void erase() {}
}
 
class Circle extends Shape {
	void draw() {
		System.out.println("Circle.draw()");
	}
	void erase() {
		System.out.println("Circle.erase()");
	}
}
 
class Square extends Shape {
	void draw() {
		System.out.println("Square.draw()");
	}
	void erase() {
		System.out.println("Square.erase()");
	}
}
 
class Triangle extends Shape {
	void draw() {
		System.out.println("Triangle.draw()");
	}
	void erase() {
		System.out.println("Triangle.erase()");
	}
}
 
// A "factory" that randomly creates shapes:
class RandomShapeGenerator {
	private Random rand = new Random();
	public Shape next() {
		switch(rand.nextInt(3)) {
			default:
			case 0: return new Circle();
			case 1: return new Square();
			case 2: return new Triangle();
		}
	}
}
 
public class Shapes {
	private static Test monitor = new Test();
	private static RandomShapeGenerator gen =
		new RandomShapeGenerator();
	public static void main(String[] args) {
		Shape[] s = new Shape[9];
		// Fill up the array with shapes:
		for(int i = 0; i < s.length; i++)
			s[i] = gen.next();
		// Make polymorphic method calls:
		for(int i = 0; i < s.length; i++)
			s[i].draw();
		monitor.expect(new Object[] {
			new TestExpression("%% (Circle|Square|Triangle)"
				+ "\\.draw\\(\\)", s.length)
		});
	}
} ///:~

The base class Shape establishes the common interface to anything inherited from Shape-that is, all shapes can be drawn and erased. The derived classes override these definitions to provide unique behavior for each specific type of shape.

RandomShapeGenerator is a kind of "factory" that produces a reference to a randomly-selected Shape object each time you call its next( ) method. Note that the upcasting happens in the return statements, each of which takes a reference to a Circle, Square, or Triangle and sends it out of next( ) as the return type, Shape. So whenever you call next( ), you never get a chance to see what specific type it is, since you always get back a plain Shape reference.

main( ) contains an array of Shape references filled through calls to RandomShapeGenerator.next( ). At this point you know you have Shapes, but you don't know anything more specific than that (and neither does the compiler). However, when you step through this array and call draw( ) for each one, the correct type-specific behavior magically occurs, as you can see from the output when you run the program.

The point of choosing the shapes randomly is to drive home the understanding that the compiler can have no special knowledge that allows it to make the correct calls at compile time. All the calls to draw( ) must be made through dynamic binding.

Now let's return to the musical instrument example. Because of polymorphism, you can add as many new types as you want to the system without changing the tune( ) method. In a well-designed OOP program, most or all of your methods will follow the model of tune( ) and communicate only with the base-class interface. Such a program is extensible because you can add new functionality by inheriting new data types from the common base class. The methods that manipulate the base-class interface will not need to be changed at all to accommodate the new classes.

Consider what happens if you take the instrument example and add more methods in the base class and a number of new classes. Here's the diagram:

All these new classes work correctly with the old, unchanged tune( ) method. Even if tune( ) is in a separate file and new methods are added to the interface of Instrument, tune( ) will still work correctly, even without recompiling it. Here is the implementation of the diagram:

//: c07:music3:Music3.java
// An extensible program.
package c07.music3;
import com.bruceeckel.simpletest.*;
import c07.music.Note;
 
class Instrument {
	void play(Note n) {
		System.out.println("Instrument.play() " + n);
	}
	String what() { return "Instrument"; }
	void adjust() {}
}
 
class Wind extends Instrument {
	void play(Note n) {
		System.out.println("Wind.play() " + n);
	}
	String what() { return "Wind"; }
	void adjust() {}
}
 
class Percussion extends Instrument {
	void play(Note n) {
		System.out.println("Percussion.play() " + n);
	}
	String what() { return "Percussion"; }
	void adjust() {}
}
 
class Stringed extends Instrument {
	void play(Note n) {
		System.out.println("Stringed.play() " + n);
	}
	String what() { return "Stringed"; }
	void adjust() {}
}
 
class Brass extends Wind {
	void play(Note n) {
		System.out.println("Brass.play() " + n);
	}
	void adjust() {
		System.out.println("Brass.adjust()");
	}
}
 
class Woodwind extends Wind {
	void play(Note n) {
		System.out.println("Woodwind.play() " + n);
	}
	String what() { return "Woodwind"; }
}
 
public class Music3 {
	private static Test monitor = new Test();
	// Doesn't care about type, so new types
	// added to the system still work right:
	public static void tune(Instrument i) {
		// ...
		i.play(Note.MIDDLE_C);
	}
	public static void tuneAll(Instrument[] e) {
		for(int i = 0; i < e.length; i++)
			tune(e[i]);
	}
	public static void main(String[] args) {
		// Upcasting during addition to the array:
		Instrument[] orchestra = {
			new Wind(),
			new Percussion(),
			new Stringed(),
			new Brass(),
			new Woodwind()
		};
		tuneAll(orchestra);
		monitor.expect(new String[] {
			"Wind.play() Middle C",
			"Percussion.play() Middle C",
			"Stringed.play() Middle C",
			"Brass.play() Middle C",
			"Woodwind.play() Middle C"
		});
	}
} ///:~

The new methods are what( ), which returns a String reference with a description of the class, and adjust( ), which provides some way to adjust each instrument.

In main( ), when you place something inside the orchestra array, you automatically upcast to Instrument.

You can see that the tune( ) method is blissfully ignorant of all the code changes that have happened around it, and yet it works correctly. This is exactly what polymorphism is supposed to provide. Changes in your code don't cause damage to parts of the program that should not be affected. Put another way, polymorphism is an important technique for the programmer to "separate the things that change from the things that stay the same."

Here's something you might innocently try to do:

//: c07:PrivateOverride.java
// Abstract classes and methods.
import com.bruceeckel.simpletest.*;
 
public class PrivateOverride {
	private static Test monitor = new Test();
	private void f() {
		System.out.println("private f()");
	}
	public static void main(String[] args) {
		PrivateOverride po = new Derived();
		po.f();
		monitor.expect(new String[] {
			"private f()"
		});
	}
}
 
class Derived extends PrivateOverride {
	public void f() {
		System.out.println("public f()");
	}
} ///:~

You might reasonably expect the output to be "public f( )", but a private method is automatically final, and is also hidden from the derived class. So Derived's f( ) in this case is a brand new method; it's not even overloaded, since the base-class version of f( ) isn't visible in Derived.

The result of this is that only non-private methods may be overridden, but you should watch out for the appearance of overriding private methods, which generates no compiler warnings, but doesn't do what you might expect. To be clear, you should use a different name from a private base-class method in your derived class.

The order of constructor calls was briefly discussed in Chapter 4 and again in Chapter 6, but that was before polymorphism was introduced.

A constructor for the base class is always called during the construction process for a derived class, chaining up the inheritance hierarchy so that a constructor for every base class is called. This makes sense because the constructor has a special job: to see that the object is built properly. A derived class has access to its own members only, and not to those of the base class (whose members are typically private). Only the base-class constructor has the proper knowledge and access to initialize its own elements. Therefore, it's essential that all constructors get called, otherwise the entire object wouldn't be constructed. That's why the compiler enforces a constructor call for every portion of a derived class. It will silently call the default constructor if you don't explicitly call a base-class constructor in the derived-class constructor body. If there is no default constructor, the compiler will complain. (In the case where a class has no constructors, the compiler will automatically synthesize a default constructor.)

Let's take a look at an example that shows the effects of composition, inheritance, and polymorphism on the order of construction:

//: c07:Sandwich.java
// Order of constructor calls.
package c07;
import com.bruceeckel.simpletest.*;
 
class Meal {
	Meal() { System.out.println("Meal()"); }
}
 
class Bread {
	Bread() { System.out.println("Bread()"); }
}
 
class Cheese {
	Cheese() { System.out.println("Cheese()"); }
}
 
class Lettuce {
	Lettuce() { System.out.println("Lettuce()"); }
}
 
class Lunch extends Meal {
	Lunch() { System.out.println("Lunch()"); }
}
 
class PortableLunch extends Lunch {
	PortableLunch() { System.out.println("PortableLunch()");}
}
 
public class Sandwich extends PortableLunch {
	private static Test monitor = new Test();
	private Bread b = new Bread();
	private Cheese c = new Cheese();
	private Lettuce l = new Lettuce();
	public Sandwich() {
		System.out.println("Sandwich()");
	}
	public static void main(String[] args) {
		new Sandwich();
		monitor.expect(new String[] {
			"Meal()",
			"Lunch()",
			"PortableLunch()",
			"Bread()",
			"Cheese()",
			"Lettuce()",
			"Sandwich()"
		});
	}
} ///:~

This example creates a complex class out of other classes, and each class has a constructor that announces itself. The important class is Sandwich, which reflects three levels of inheritance (four, if you count the implicit inheritance from Object) and three member objects. You can see the output when a Sandwich object is created in main( ). This means that the order of constructor calls for a complex object is as follows:

• The base-class constructor is called. This step is repeated recursively such that the root of the hierarchy is constructed first, followed by the next-derived class, etc., until the most-derived class is reached.
• Member initializers are called in the order of declaration.
• The body of the derived-class constructor is called.

The order of the constructor calls is important. When you inherit, you know all about the base class and can access any public and protected members of the base class. This means that you must be able to assume that all the members of the base class are valid when you're in the derived class. In a normal method, construction has already taken place, so all the members of all parts of the object have been built. Inside the constructor, however, you must be able to assume that all members that you use have been built. The only way to guarantee this is for the base-class constructor to be called first. Then when you're in the derived-class constructor, all the members you can access in the base class have been initialized. Knowing that all members are valid inside the constructor is also the reason that, whenever possible, you should initialize all member objects (that is, objects placed in the class using composition) at their point of definition in the class (e.g., b, c, and l in the preceding example). If you follow this practice, you will help ensure that all base class members and member objects of the current object have been initialized. Unfortunately, this doesn't handle every case, as you will see in the next section.

When using composition and inheritance to create a new class, most of the time you won't have to worry about cleaning up; subobjects can usually be left to the garbage collector. If you do have cleanup issues, you must be diligent and create a dispose( ) method (the name I have chosen to use here; you may come up with something better) for your new class. And with inheritance, you must override dispose( ) in the derived class if you have any special cleanup that must happen as part of garbage collection. When you override dispose( ) in an inherited class, it's important to remember to call the base-class version of dispose( ), since otherwise the base-class cleanup will not happen. The following example demonstrates this:

//: c07:Frog.java
// Cleanup and inheritance.
import com.bruceeckel.simpletest.*;
 
class Characteristic {
	private String s;
	Characteristic(String s) {
		this.s = s;
		System.out.println("Creating Characteristic " + s);
	}
	protected void dispose() {
		System.out.println("finalizing Characteristic " + s);
	}
}
 
class Description {
	private String s;
	Description(String s) {
		this.s = s;
		System.out.println("Creating Description " + s);
	}
	protected void dispose() {
		System.out.println("finalizing Description " + s);
	}
}
 
class LivingCreature {
	private Characteristic p = new Characteristic("is alive");
	private Description t =
		new Description("Basic Living Creature");
	LivingCreature() {
		System.out.println("LivingCreature()");
	}
	protected void dispose() {
		System.out.println("LivingCreature dispose");
		t.dispose();
		p.dispose();
	}
}
 
class Animal extends LivingCreature {
	private Characteristic p= new Characteristic("has heart");
	private Description t =
		new Description("Animal not Vegetable");
	Animal() {
		System.out.println("Animal()");
	}
	protected void dispose() {
		System.out.println("Animal dispose");
		t.dispose();
		p.dispose();
		super.dispose();
	}
}
 
class Amphibian extends Animal {
	private Characteristic p =
		new Characteristic("can live in water");
	private Description t =
		new Description("Both water and land");
	Amphibian() {
		System.out.println("Amphibian()");
	}
	protected void dispose() {
		System.out.println("Amphibian dispose");
		t.dispose();
		p.dispose();
		super.dispose();
	}
}
 
public class Frog extends Amphibian {
	private static Test monitor = new Test();
	private Characteristic p = new Characteristic("Croaks");
	private Description t = new Description("Eats Bugs");
	public Frog() {
		System.out.println("Frog()");
	}
	protected void dispose() {
		System.out.println("Frog dispose");
		t.dispose();
		p.dispose();
		super.dispose();
	}
	public static void main(String[] args) {
		Frog frog = new Frog();
		System.out.println("Bye!");
		frog.dispose();
		monitor.expect(new String[] {
			"Creating Characteristic is alive",
			"Creating Description Basic Living Creature",
			"LivingCreature()",
			"Creating Characteristic has heart",
			"Creating Description Animal not Vegetable",
			"Animal()",
			"Creating Characteristic can live in water",
			"Creating Description Both water and land",
			"Amphibian()",
			"Creating Characteristic Croaks",
			"Creating Description Eats Bugs",
			"Frog()",
			"Bye!",
			"Frog dispose",
			"finalizing Description Eats Bugs",
			"finalizing Characteristic Croaks",
			"Amphibian dispose",
			"finalizing Description Both water and land",
			"finalizing Characteristic can live in water",
			"Animal dispose",
			"finalizing Description Animal not Vegetable",
			"finalizing Characteristic has heart",
			"LivingCreature dispose",
			"finalizing Description Basic Living Creature",
			"finalizing Characteristic is alive"
		});
	}
} ///:~

Each class in the hierarchy also contains a member objects of types Characteristic and Description, which must also be disposed. The order of disposal should be the reverse of the order of initialization, in case one subobject is dependent on another. For fields, this means the reverse of the order of declaration (since fields are initialized in declaration order). For base classes (following the form that's used in C++ for destructors), you should perform the derived-class cleanup first, then the base-class cleanup. That's because the derived-class cleanup could call some methods in the base class that require the base-class components to be alive, so you must not destroy them prematurely. From the output you can see that all parts of the Frog object are disposed in reverse order of creation.

From this example, you can see that although you don't always need to perform cleanup, when you do, the process requires care and awareness.

The hierarchy of constructor calls brings up an interesting dilemma. What happens if you're inside a constructor and you call a dynamically-bound method of the object being constructed? Inside an ordinary method, you can imagine what will happen: The dynamically-bound call is resolved at run time, because the object cannot know whether it belongs to the class that the method is in or some class derived from it. For consistency, you might think this is what should happen inside constructors.

This is not exactly the case. If you call a dynamically-bound method inside a constructor, the overridden definition for that method is used. However, the effect can be rather unexpected and can conceal some difficult-to-find bugs.

Conceptually, the constructor's job is to bring the object into existence (which is hardly an ordinary feat). Inside any constructor, the entire object might be only partially formed-you can know only that the base-class objects have been initialized, but you cannot know which classes are inherited from you. A dynamically bound method call, however, reaches "outward" into the inheritance hierarchy. It calls a method in a derived class. If you do this inside a constructor, you call a method that might manipulate members that haven't been initialized yet-a sure recipe for disaster.

You can see the problem in the following example:

//: c07:PolyConstructors.java
// Constructors and polymorphism
// don't produce what you might expect.
import com.bruceeckel.simpletest.*;
 
abstract class Glyph {
	abstract void draw();
	Glyph() {
		System.out.println("Glyph() before draw()");
		draw();
		System.out.println("Glyph() after draw()");
	}
}
 
class RoundGlyph extends Glyph {
	private int radius = 1;
	RoundGlyph(int r) {
		radius = r;
		System.out.println(
			"RoundGlyph.RoundGlyph(), radius = " + radius);
	}
	void draw() {
		System.out.println(
			"RoundGlyph.draw(), radius = " + radius);
	}
}
 
public class PolyConstructors {
	private static Test monitor = new Test();
	public static void main(String[] args) {
		new RoundGlyph(5);
		monitor.expect(new String[] {
			"Glyph() before draw()",
			"RoundGlyph.draw(), radius = 0",
			"Glyph() after draw()",
			"RoundGlyph.RoundGlyph(), radius = 5"
		});
	}
} ///:~

In Glyph, the draw( ) method is abstract, so it is designed to be overridden. Indeed, you are forced to override it in RoundGlyph. But the Glyph constructor calls this method, and the call ends up in RoundGlyph.draw( ), which would seem to be the intent. But if you look at the output, you can see that when Glyph's constructor calls draw( ), the value of radius isn't even the default initial value 1. It's 0. This would probably result in either a dot or nothing at all being drawn on the screen, and you'd be left staring, trying to figure out why the program won't work.

The order of initialization described in the earlier section isn't quite complete, and that's the key to solving the mystery. The actual process of initialization is:

• The storage allocated for the object is initialized to binary zero before anything else happens.
• The base-class constructors are called as described previously. At this point, the overridden draw( ) method is called (yes, before the RoundGlyph constructor is called), which discovers a radius value of zero, due to Step 1.
• Member initializers are called in the order of declaration.
• The body of the derived-class constructor is called.

There's an upside to this, which is that everything is at least initialized to zero (or whatever zero means for that particular data type) and not just left as garbage. This includes object references that are embedded inside a class via composition, which become null. So if you forget to initialize that reference, you'll get an exception at run time. Everything else gets zero, which is usually a telltale value when looking at output.

On the other hand, you should be pretty horrified at the outcome of this program. You've done a perfectly logical thing, and yet the behavior is mysteriously wrong, with no complaints from the compiler. (C++ produces more rational behavior in this situation.) Bugs like this could easily be buried and take a long time to discover.

As a result, a good guideline for constructors is, "Do as little as possible to set the object into a good state, and if you can possibly avoid it, don't call any methods." The only safe methods to call inside a constructor are those that are final in the base class. (This also applies to private methods, which are automatically final.) These cannot be overridden and thus cannot produce this kind of surprise.

When studying inheritance, it would seem that the cleanest way to create an inheritance hierarchy is to take the "pure" approach. That is, only methods that have been established in the base class or interface are to be overridden in the derived class, as seen in this diagram:

This can be called a pure "is-a" relationship because the interface of a class establishes what it is. Inheritance guarantees that any derived class will have the interface of the base class and nothing less. If you follow this diagram, derived classes will also have no more than the base-class interface.

This can be thought of as pure substitution, because derived class objects can be perfectly substituted for the base class, and you never need to know any extra information about the subclasses when you're using them:

That is, the base class can receive any message you can send to the derived class because the two have exactly the same interface. All you need to do is upcast from the derived class and never look back to see what exact type of object you're dealing with. Everything is handled through polymorphism.

When you see it this way, it seems like a pure is-a relationship is the only sensible way to do things, and any other design indicates muddled thinking and is by definition broken. This too is a trap. As soon as you start thinking this way, you'll turn around and discover that extending the interface (which, unfortunately, the keyword extends seems to encourage) is the perfect solution to a particular problem. This could be termed an "is-like-a" relationship, because the derived class is like the base class-it has the same fundamental interface-but it has other features that require additional methods to implement:

While this is also a useful and sensible approach (depending on the situation), it has a drawback. The extended part of the interface in the derived class is not available from the base class, so once you upcast, you can't call the new methods:

If you're not upcasting in this case, it won't bother you, but often you'll get into a situation in which you need to rediscover the exact type of the object so you can access the extended methods of that type. The following section shows how this is done.

Since you lose the specific type information via an upcast (moving up the inheritance hierarchy), it makes sense that to retrieve the type information-that is, to move back down the inheritance hierarchy-you use a downcast. However, you know an upcast is always safe; the base class cannot have a bigger interface than the derived class. Therefore, every message you send through the base class interface is guaranteed to be accepted. But with a downcast, you don't really know that a shape (for example) is actually a circle. It could instead be a triangle or square or some other type.

To solve this problem, there must be some way to guarantee that a downcast is correct, so that you won't accidentally cast to the wrong type and then send a message that the object can't accept. This would be quite unsafe.

In some languages (like C++) you must perform a special operation in order to get a type-safe downcast, but in Java, every cast is checked! So even though it looks like you're just performing an ordinary parenthesized cast, at run time this cast is checked to ensure that it is in fact the type you think it is. If it isn't, you get a ClassCastException. This act of checking types at run time is called run-time type identification (RTTI). The following example demonstrates the behavior of RTTI:

//: c07:RTTI.java
// Downcasting & Run-Time Type Identification (RTTI).
// {ThrowsException}
 
class Useful {
	public void f() {}
	public void g() {}
}
 
class MoreUseful extends Useful {
	public void f() {}
	public void g() {}
	public void u() {}
	public void v() {}
	public void w() {}
}
 
public class RTTI {
	public static void main(String[] args) {
		Useful[] x = {
			new Useful(),
			new MoreUseful()
		};
		x[0].f();
		x[1].g();
		// Compile time: method not found in Useful:
		//! x[1].u();
		((MoreUseful)x[1]).u(); // Downcast/RTTI
		((MoreUseful)x[0]).u(); // Exception thrown
	}
} ///:~

As in the diagram, MoreUseful extends the interface of Useful. But since it's inherited, it can also be upcast to a Useful. You can see this happening in the initialization of the array x in main( ). Since both objects in the array are of class Useful, you can send the f( ) and g( ) methods to both, and if you try to call u( ) (which exists only in MoreUseful), you'll get a compile-time error message.

If you want to access the extended interface of a MoreUseful object, you can try to downcast. If it's the correct type, it will be successful. Otherwise, you'll get a ClassCastException. You don't need to write any special code for this exception, since it indicates a programmer error that could happen anywhere in a program.

There's more to RTTI than a simple cast. For example, there's a way to see what type you're dealing with before you try to downcast it. All of Chapter 10 is devoted to the study of different aspects of Java run-time type identification.