Good question can you figure it out

[Tom Tolman]

class A {
   String as = name();
   String name() {
    return "A";
   }
 }
 
 class B extends A {
   String as = "C";
   String name() {
    return "B";
   }
 }
 
 public class Test2 {
   public static void main(String[] args) {
     A a = new B();
     System.out.println(a.as);
   }
 }

I found this on a webpage... and changed it a bit..

([C0DE][/C0DE] tags added)
[ September 03, 2004: Message edited by: Barry Gaunt ]

[Ken Weller]

"B" is the output.

Variables are shadowed, methods are overridden.

A new instance of "B" is assigned to "a" (which is type "A"). The call to "a.as" references "as" in class "A", which is set to "name()". Because "B" overrides "name()", this results in "B".

Someone correct me if I'm wrong.

[Jessica Sant]

"SQL Friend"-
Welcome to the JavaRanch! We like to keep a professional lookin' image here at the JavaRanch, and don't like it when people try to show up the one-eyed moose. So if you could change your display name (click here), that'd be just dandy. (If you'd like a more thorough reason as to why I'm asking you to change your name, check out the Naming Policy.)

Thanks! And again, Welcome to the JavaRanch!

[Natta Pon]

Ken, You're right
First I though it should return "A". Then I try to compile this code and got result "B".
Because I miss the line 'as = name()' in class A that make result come out as you explain.

But I think variables are not shadowed.
If you change the line 'as = name();' to 'as = "A";'
This program will show "A" because attribute member of class cannot be polymophism

[JPraveen Kumar]

Can somebody please explain why the output should not be 'C'?
According to me, the lookup points to a child instance which has the instance variable as="C" then why should it lookup via the name function defined in class A? This is an excellent example of child class shadowing parent class instance variable. Then why should parent definition be looked up at all?

Regards JPraveen

[Jay Pawar]

Hello all,
I simply fail to understand why "a.as" tries to access "as" instance variable of the base class. Does anybody know in depth why the behaviour is like this ?
Thanks !!!

[Piyush Jain]

Hi,

a.as tries to access "as"instance variable of the base class because

A a = new B();

a was declared as a variable of type A even if it is referencing to a new B();

Always, the object "type" will define its behavior.

I hope this will help.

hey guys, anybody already taken the SCJP, i am taking it on 11th, any inputs?

Thanks
Piyush

[Jay Pawar]

Piyush,
I am confused here again. I thought Java has "virtualness" by default; unlike in C++ you have to specify the keyword virtual for your method in your base class . This will ensure that the overrriden method in your derived class is called and this is achieved by "late binding". During late binding the contents of the object is all that matters and not the type of the object.
Confused !!!

[Piyush Jain]

Hi,

Sorry about the previous post, I was wrong. This is what seems to be the logical conclusion.

Instance methods (not static) make sure that the overridden methods are called even if the object is parent type. In other words, runtime type (defined by new Objecttype()) of the variable is checked rather than the compile type. for example

public class parent
{
public void Method()
{
System.out.println("Method in parent class called");
}
}

public class child extends parent
{
public void Method()
{
System.out.println("Method in child class called");
}

}

public class test
{
public static void main(String [] args)
{
parent a1 = new child();
}

}

This should execute the method in child class.
Jay, Try changing the method to static and see what happens, it should execute the one in parent class.

I have not executed this program, so you should try it.

so the answer for the previous question would be "B" .

please correct me if i am wrong!!

Thanks

[Piyush Jain]

Sorry,

add this line to main

a1.Method();

Thanks

[marc weber]

While I can't say that I fully appreciate the value of "encapsulation," I will suggest that this apparent discrepancy wouldn't occur if the variables were all private -- to be manipulated and/or returned only by methods, rather than accessed directly.

Right?

[Jay Pawar]

Looks like the virtual behaviour is applicable only to methods and not the instance variable. I tried the code below

  
class parent
{
public String s = "Parent";
}
 
class child extends parent
{
public String s = "Child";
 
}
 
public class test
{
public static void main(String [] args)
{
parent a1 = new child();
System.out.println("The answer is:"+a1.s);
}
 
}
The answer is :-P	 arent

Interesting thing is the String data members are NOT STATIC, even if you make the String data members STATIC, the output is same.

For now I am just going to burn this in my gray matter
Virtualness/Virtuality only for instance methods and NOT for instance variable.

[Jay Pawar]

Correction !!! The answer is Parent

[Jay Pawar]

I agree with you Marc.

[Tom Tolman]

One way to think about virtualness is this- how is it actually getting the data?

In a C compiler the virtual function table is built- it looks up the method address depending on the run time evaluation of the class type.

In Java it must be the same- a virtual method table is built. What does this mean? It means it contains a collection of pointers which point to the correct address to jump to depending on the class type it finds at the moment it is forced to evaluate the function.

It literally jumps to the address.

Now it does not build a virtual variable table- what is it going do to evaluate the class? It has a pointer to the class itself (the reference) and now looks at the variable. It doesn't have any table to look through to resolve the variable- it only has its current notion of what the class is. So it uses this current notion. How is it supposed to know that there is a subclass which contains this variable? All it has is a pointer to what it thinks of as a base class, and a type. It knows enough about the base class to know its variables. it knows that the type will cause it to jump through the virtual method table. How is it supposed to find the information outside of its frame of reference?

The moral here is: Java did not implement a virtual variable table. They could have, but it would have made the implementation more complex- virtual functions are tremendously useful- I doubt you will find it easy to me to explain how virtual variables would be useful. This is probably the reason- there is no motivation (except for the aesthetic of completeness).

Therefore- methods ARE resolved on virtual method table, variables ARE NOT because there is no freaking table!

[Murtuza Akhtari]

hey Jay,

with regards to your question---

Instance Variables, Static Variables and Static Methods are bound at compile time whereas Instance Methods are bound at runtime.

With that in mind---

the compiler checks only for the reference type, since the new operator only finishes after the object has been created at runtime.
So at compile time, the variables are bound with the reference type (be it the parent reference type or the child itself)

Thus your variable 'as' returns Parent as the output...however in the very first question...it uses an Instance Method...which is bound at runtime..The JVM at runtime checks for the ACTUAL type of object created which was B (A a = new B() )

Since the object is of type B...at runtime...the instance method is bound to class B as opposed to class A !!


Hope that helps !!

[Jay Pawar]

Thanks a lot Tom and Murtuza.
Tom, what you have explained is absolutely correct. I realized this when I was driving back home from work
No vTable for holding instance variables.