Runtime polymorphic behavior
However, the following call to the method does constitute runtime polymorphism.
The statement in Listing 4 casts the reference down to type A and calls the method named m() on that reference.
It may not come as a surprise to you that the call to the method shown in Listing 4 also compiles and runs successfully.
Listing 4 . Polymorphic behavior. |
---|
((A)var).m(); |
The method output
Here is the punch line. Not only does the statement in Listing 4 compile and run successfully, it produces the following output, (which is exactly the same output as before) :
m in class B
Same method executed in both cases
It is important to note that this output, (produced by casting the reference variable to type A instead of type B ) , is exactly the same as that produced by the earlier call to the method when the reference was cast to type B . This means that the same version of the method was executed in both cases.
This confirms that, even though the type of the reference was converted to type A , (rather than type Object or type B ) , the overridden version of the method defined in class B was actually executed.
This is an example of runtime polymorphic behavior.
The version of the method that was executed was based on
- the actual type of the object, B , and
- not on the type of the reference, A .
This is an extremely powerful and useful concept.
Another call to the method
Now take a look at the statement in Listing 5 . Will this statement compile and execute successfully? If so, which version of the method will be executed?
Listing 5 . Source of a compiler error. |
---|
var.m(); |
Compiler error
The code in Listing 5 attempts, unsuccessfully, to call the method named m() using the reference variable named var , which is of type Object . The result is a compiler error, which, depending on your version of the JDK, will be similar to the following:
Poly03.java:40: cannot resolve symbol
symbol : method m ()location: class java.lang.Object
var.m();^
Some important rules
The Object class does not define a method named m() . Therefore, the overridden method named m() in the class named B is not an overridden version of a method that is defined in the class named Object .
Necessary, but not sufficient
Runtime polymorphism based on class inheritance requires that the type of the reference variable be a superclass of the class from which the object (on which the method will be called) is instantiated.
However, while necessary, that is not sufficient.
The type of the reference variable must also be a class that either defines or inherits the method that will ultimately be called on the object.
This method is not defined in the Object class
Since the class named Object neither defines nor inherits the method named m() , a reference of type Object does not qualify as a participant in runtime polymorphic behavior in this case. The attempt to use it as a participant resulted in the compiler error given above.
One additional scenario
Before leaving this topic, let's look at one additional scenario to help you distinguish what is, and what is not, runtime polymorphism. Consider the code shown in Listing 6 .