Sub extends Base.....right?

[Gary Marshall]

class Base
{
void methodA()
{
System.out.println("base - MethodA");
}
}
 
class Sub extends Base
{
public void methodA()
{
System.out.println("sub - MethodA");
}
public void methodB()
{
System.out.println("sub - MethodB");
}
public static void main(String args[])
{
Base b=new Sub(); //1
b.methodA(); //2
b.methodB(); //3
}
}

I am told "b" is declared to be a reference of class Base and methodB() is not defined in Base. So the compiler cannot accept the statement
b.methodB() because it only verifies the validity of a call by looking at the declared class of the reference. So now the compiler only looks at the reference type "Base" and not the object type "Sub" when determining if a method exists?

Letsee if I got this right: The compiler looks at the reference type (to the left of the equals sign) and the jvm looks at the object (to the right of the equals sign). And if there are overriden methods the jvm again looks at the object to determine which method to call.
Does that about sum this mess up?
Thank you
Gary

[Keith Lynn]

I'm not sure exactly what you're question is. When the object is referred to as a Base object, it can only see methods defined in the Base class.

[Gary Marshall]

My question really is: Why doesn't the compiler see that "b" is a new "Sub"?
..... Base b=new Sub();

Gary

[Tony Smith]

I skim through your post and believe you are correct. That is the whole point of polymorphism. Dynamic binding.

[Gary Marshall]

Dynamic binding is all well and good, but I need to get a clear understanding of what that compiler understands before I take the exam.

And so far I'm not understanding why the compiler doesn't see that "b" is a new "Sub"?
..... Base b=new Sub();

Is it the rule that the compiler only looks at the declared type to the left of the equals sign?
Gary

[Tony Smith]

Yes, I believe that is the rule and is true what you said in the first post.

"even though the compiler only knows about the declared reference type, the JVM at runtime knows what the object really is."

That is directly from the kathy book. Hence it's always good to get more than 1 book to read. The second book will usually clears up some doubts the first book fails to explain. And when you finish the second book, you can go back and reread the first book. That's how I do it. Do you have the headfirst java book? You should get it if you don't have it.

[Keith Lynn]

Originally posted by Gary Marshall:
Dynamic binding is all well and good, but I need to get a clear understanding of what that compiler understands before I take the exam.

And so far I'm not understanding why the compiler doesn't see that "b" is a new "Sub"?
..... Base b=new Sub();

Is it the rule that the compiler only looks at the declared type to the left of the equals sign?
Gary

This is the same principle as in the following program.

public class Test {
   private int num;
 
   public int getNum() {
      return(num);
   }
 
   public void equals(Object o) {
      return(o.getNum() == getNum());
   }
 
   public static void main(String[] args) {
      Test test = new Test(1);
 
      Test test1 = new Test(2);
 
      System.out.println(test.equals(test1));
   }
}

In the equals method, we have a compile-time error.

Even though the actual reference is to a Test object, when it is sent to the equals method, the parameter reference type is Object. That means that I can only call methods on the parameter that are defined in Object.

[Burkhard Hassel]

Gary Marshall filed this complaint:

Dynamic binding is all well and good, but I need to get a clear understanding of what that compiler understands before I take the exam.

And so far I'm not understanding why the compiler doesn't see that "b" is a new "Sub"?
..... Base b=new Sub();

Is it the rule that the compiler only looks at the declared type to the left of the equals sign?

Yes. With your snippet, it looks as if the compiler is a bit lazy because it does not look at the object. But in your example there is only one static line, this does not necessaryly have to be so.

E.g.

class Main {
public static void main(String[] args) {
Number[] nums = new Number[12];
for (int k=0; k<nums.length; k++) {
double random = Math.random();
if(random < 0.5)
nums[k] = new Integer(k);
else
nums[k] = new Double(k);
}

for(Number number : nums) {
if (number instanceof Double) {
System.out.print(number + " * pi = ");
Double d = (Double) number;
System.out.println(d * Math.PI);
}else {
System.out.print("Don't like it to multiply ");
System.out.print(number);
System.out.println( " with pi.");
}
}
}
}

Here, only at runtime it is known, if the Number is a Double or an Integer.

The compiler has no "sense" of this runtime types.



Generally speaking, if you have
Base b=new Sub();


Then only Base-methods can be invoked with variable b.
If Sub has new own methods that Base does not have, you cannot invoke them with variable b. However, you could downcast
Sub mySub = (Sub) b;
mySub.subSpecific_method();


Perhaps see also the thread with the coconut.




Yours,
Bu.
[ September 27, 2007: Message edited by: Burkhard Hassel ]