|
|
|
Advertisement
|
invokespecial and private methods
In the case of private methods, it must be possible for a subclass to
declare a method with the same signature as a private method in a
superclass. For example, consider the following code in which
interestingMethod() is declared as private in
a superclass and with package access in a subclass:
class Superclass {
private void interestingMethod() {
System.out.println("Superclass's interesting method.");
}
void exampleMethod() {
interestingMethod();
}
}
class Subclass extends Superclass {
void interestingMethod() {
System.out.println("Subclass's interesting method.");
}
public static void main(String args[]) {
Subclass me = new Subclass();
me.exampleMethod();
}
}
When you invoke main() in Subclass as defined
above, it must print "Superclass's interesting
method." If invokevirtual were used, it would
print "Subclass's interesting method." Why?
Because the virtual machine would choose the
interestingMethod() to call based on the actual class of
the object, which is Subclass. So it will use
Subclass's interestingMethod(). On the other
hand, with invokespecial the virtual machine will select
the method based on the type of the reference, so
Superclass's version of interestingMethod()
will be invoked.
invokespecial and super
When invoking a method with the super keyword, as in
super.someMethod(), you want the superclass's version of a
method to be invoked -- even if the current class overrides the method.
Once again, invokevirtual would invoke the current class's
version, so it can't be used in this situation.
The invokeinterface instruction
The invokeinterface opcode performs the same function as
invokevirtual. The only difference is that
invokeinterface is used when the reference is of an
interface type.
To understand why a separate opcode is necessary for interface references, you must understand a bit about method tables. When the Java virtual machine loads a class file, it may create a method table for the class. (Whether or not a method table is actually created is the decision of each virtual machine designer; however, it is likely that commercial JVMs will create method tables.) A method table is just an array of direct references to the bytecodes for each instance method that can be invoked on an object, including methods inherited from superclasses.
The JVM uses a different opcode to invoke a method given an interface reference because it can't make as many assumptions about the method table offset as it can given a class reference. If the JVM has a class reference, it knows each method will always occupy the same position in the method table, independent of the actual class of the object. This is not true with an interface reference: The method could occupy different locations for different classes that implement the same interface.
|
Sponsored Links
|