Achint Verma wrote:So, according to the above statement(...the compiler assumes you are calling the supertype version of the method) , shouldn't the output be "Super Animal eats" ? The actual output is rather "Super Cow eats".I am just confused with the above statement. Can someone precisely explain me what does it mean or am I misunderstanding it.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Junilu Lacar wrote:Assuming Kathy did not a mistake, I think what she's trying to do is explain the difference between compile-time interpretation of code by the compiler and runtime execution of code by the JVM. At compile time, the compiler can check type compatibility and assignability. The compiler will accept Line 12 in your listing just fine. However, despite the SuperAnimal reference "sa" being set to point to a subclass, SuperCow, the compiler doesn't really "recognize" that it is SuperCow.eat() that should be called; as far as the compiler is concerned, SuperAnimal.eat() is called. This is because the reference type is SuperAnimal.
The runtime behavior is different. This is where the virtual nature of the eat() method comes out and polymorphism kicks in. It's been quite a while since I've even had to think about this in low-level terms but if I recall correctly, at runtime there is something called a dispatch table which the runtime system uses to figure out the correct version of eat() to execute. The runtime system sees the reference to a SuperAnimal but recognizes that the actual object is a SuperCow. It then goes to the dispatch table, looks up the eat() method for SuperCow (the runtime type) and invokes that method instead of the SuperAnimal.eat().
Hope this helps. (And someone correct me if I'm wrong)
"You douse my soul with gasoline, you flicked a match into my brain"
Jo Joseph wrote:Any time you have a class that inherits a method from a superclass, you have the
opportunity to override the method (unless, the method is marked final).
The key benefit of overriding is the ability to define behavior that's
specific to a particular subclass type.
.......
class Horse extends Animal {
public void eat() {
System.out.println("Horse eating hay, oats, "
+ "and horse treats");
}
public void buck() { }
}
..........
Animal c = new Horse();
c.buck(); // Can't invoke buck();
// Animal class doesn't have that method
"You douse my soul with gasoline, you flicked a match into my brain"
hari shankar bhatt wrote:If I'm guessing it right...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
In your specific case: any method that is defined in the class on the left-hand side of the assignment can be called, but when it is, it will use the implementation defined by the class on the right-hand side.
That make it any clearer?
Winston
"You douse my soul with gasoline, you flicked a match into my brain"