Java Reference
In-Depth Information
Dynamic Binding and Interfaces
Java uses dynamic binding (also known as runtime binding or late binding) when a method is invoked using a
variable of an interface type. Consider the following code:
Walkable john = a Walkable object reference...
john.walk();
The variable john has two types: a compile-time type and a runtime type. Its compile-time type is its declared
type, which is Walkable . The compiler knows about the compile-time type of a variable. When the code john.walk()
is compiled, the compiler has to verify that this call is valid according to all pieces of information that are available at
compile time. The compiler adds instruction similar to the following for the john.walk() method invocation:
invokeinterface #5, 1; //InterfaceMethod com/jdojo/interfaces/Walkable.walk:()V
The above instruction states that the john.walk() method invocation is being made on a variable of an interface
type, which is Walkable . The object to which the variable john refers at runtime is its runtime type. The compiler
does not know about the runtime type of the variable john . The variable john may refer to an object of a Person class,
a Turtle class, a Duck class, or any other class that implements the Walkable interface. The compiler does not state
which implementation of the walk() method should be used, when john.walk() is executed. The runtime decides
the implementation of the walk() method to invoke as follows:
john refers to. For
It gets the information about the class of the object to which the variable
example, consider the following snippet of code:
Walkable john = new Person("John"); // john refers to a Person object
john.walk();
Here, the class type of the object to which the variable john refers to at runtime is Person .
walk() method implementation in the class that is determined in the previous
step. If the walk() method implementation is not found in that class, the runtime looks for the
walk() method's implementation in the ancestor class recursively.
It looks for the
walk() method's implementation is found in the previous step, it is executed as soon as
it is found. That is, if the walk() method's implementation is found in the class of the object
to which the variable john refers to, the runtime executes that method implementation and it
does not look for the method any further in its ancestor class.
If the walk() method's implementation is not found in the class hierarchy, the inheritance hierarchy of the
superinterfaces implemented by the class is searched. If a walk() method is found using the most specific rules of
finding methods in interfaces described previously, that method is invoked if it is a default method. If multiple default
walk() methods are found, an IncompatibleClassChangeError is thrown. If an abstract walk () method is found, an
AbstractMethodError is thrown.
If the
walk() method's implementation is still not found, a NoSuchMethodError is thrown. If all
classes are consistently compiled, you should not get this error.
If the
 
Search WWH ::




Custom Search