<< Chapter < Page Chapter >> Page >

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 .

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Object-oriented programming (oop) with java. OpenStax CNX. Jun 29, 2016 Download for free at https://legacy.cnx.org/content/col11441/1.201
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Object-oriented programming (oop) with java' conversation and receive update notifications?

Ask