Java Reference
In-Depth Information
Employee e = new Salary(“John Adams”, “Boston, MA”,
2, 2400.00);
System.out.println(“** Call mailCheck using
Salary reference **”);
s.mailCheck();
System.out.println(“\n** Call mailCheck using
Employee reference **”);
e.mailCheck();
}
}
Listing 8.9
(continued)
The output of the VirtualDemo program is shown in Figure 8.4. The program
instantiates two Salary objects—one using a Salary reference s, and the other
using an Employee reference e.
We saw earlier that invoking mailCheck() with s causes mailCheck() to
execute in the Salary class. In the following statement, the compiler sees
mailCheck() in the Salary class at compile time, and the JVM invokes
mailCheck() in the Salary class at run time:
s.mailCheck();
Invoking mailCheck() on e is quite different because e is an Employee refer-
ence. When the compiler sees the following statement, the compiler sees the
mailCheck() method in the Employee class:
e.mailCheck();
Does this mean that mailCheck() in the Employee class is invoked at run
time? No! Look closely at the output in Figure 8.4. At compile time, the com-
piler used mailCheck() in Employee to validate this statement. At run time,
however, the JVM invokes mailCheck() in the Salary class.
This behavior is referred to as
virtual method invocation
, and the methods
are referred to as
virtual methods
. All methods in Java behave in this
manner, whereby an overridden method is invoked at run time, no matter
what data type the reference is that was used in the source code at
compile time.
With virtual methods, the JVM must look down the inheritance hierarchy
and determine if a method is overridden. If the method is overridden, the child
method executes at run time, not the one in the parent that was invoked at
compile time.
