super

[giuseppe.on.usenet]

/* file: ~/dir1/Parent.java */
package dir1;
public class Parent {
protected int var = 1;
}
/* end Parent.java */

/* file: ~/dir2/Child.java */
package dir2;
import dir1.Parent;
class Child extends Parent {
public void test() {
System.out.println("var is " + var);
}

public static void main(String[] args) {
Child c = new Child();
c.test();
}
}
/* end Child.java */

/* file: ~/dir2/GrandChild.java */
package dir2;
public class GrandChild extends Child {
public void test2() {
System.out.println("super.var is " + super.var);
System.out.println("var is " + var);
}

public static void main(String[] args) {
GrandChild gc = new GrandChild();
gc.var = 2;
Child c = new Child();
gc.test2();
}
}
/* end GrandChild.java */

When I run dir2.Child, I get:
var is 1
which is what I was expecting.
When I run dir2.GrandChild, I get:
super.var is 2
var is 2
These last two variables have the same value, although I only modified
gc.var in GrandChild.java. Why?
Thank you.

 

[Joshua Cranmer]

When I run dir2.Child, I get:
var is 1
which is what I was expecting.
When I run dir2.GrandChild, I get:
super.var is 2
var is 2
These last two variables have the same value, although I only modified
gc.var in GrandChild.java. Why?

How many times did you declare a variable named `var'? By my count, you
defined it once, so `var' and `super.var' both refer to the same
variable `var', namely the one defined in Parent.

 

[Andreas Leitgeb]

How many times did you declare a variable named `var'? By my count, you
defined it once, so `var' and `super.var' both refer to the same
variable `var', namely the one defined in Parent.

I think the misunderstanding is far more basic.

To giuseppe:

In dir2.GrandChild's main, just remove the line, where you instantiate
Child, and leave the rest exactly as is. Recompile & run it. You'll
see that instantiating class Child (or not doing it) doesn't change
anything. What does this tell you?

 

[Andreas Leitgeb]

I think the misunderstanding is far more basic.

To giuseppe:

In dir2.GrandChild's main, just remove the line, where you instantiate
Child, and leave the rest exactly as is. Recompile & run it. You'll
see that instantiating class Child (or not doing it) doesn't change
anything. What does this tell you?

Alternatively, leave the line "Child c = new Child();" in, and rather
add another line "c.test()" to the end of GrandChild's main method.

 

[giuseppe.on.usenet]

I think the misunderstanding is far more basic.

To giuseppe:

In dir2.GrandChild's main, just remove the line, where you instantiate
Child, and leave the rest exactly as is.  Recompile & run it.  You'll
see that instantiating class Child (or not doing it) doesn't change
anything. What does this tell you?

I am not the author I found that code in a certification study
guide (the original question was: What will the output be?). Maybe
they instantiated the Child object just to try to confuse the reader.
Actually, I don't think the question was very simple, because you are
not supposed to use a compiler during the exam.

 

[Andreas Leitgeb]

I am not the author I found that code in a certification study
guide (the original question was: What will the output be?).

That doesn't really matter. Obviously you didn't "guess" (or know)
the answer (or you wouldn't have asked here). If you are still
surprised by "super.var" and "var" being the same value, then
I advise you to still make the experiments I suggested.

Maybe
they instantiated the Child object just to try to confuse the reader.

Not primarily to confuse him, but rather to test his confusability ;-)

 

[Lew]

That doesn't really matter. Obviously you didn't "guess" (or know)
the answer (or you wouldn't have asked here). If you are still
surprised by "super.var" and "var" being the same value, then
I advise you to still make the experiments I suggested.


Not primarily to confuse him, but rather to test his confusability ;-)

Andreas is completely correct, giuseppe. It's a test question, so of course they will include some irrelevant information ("red herrings") to see if you really know what you're doing.

It is completely unnecessary to use a compiler to answer the question once you understand the principles. Andreas's advice to use a compiler is to help you achieve that understanding. He did not suggest you use a compiler during the test, but during your study. Of course you are allowed to use a compiler when you are studying.

Unlike member methods, member variables do not override inherited variables.. It is rarely if ever necessary, and I would say never desirable to referto a variable via the 'super.' notation. If the variable is inherited, then 'super.variable' is exactly the same as 'this.variable'; both syntaxes refer to the same variable. If a variable in the child class has the same name as an inherited variable from an ancestor class, then you got problems.It is not good to name the member variable the same as an inherited member variable; the child variable "hides" the ancestor variable.
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.3>

So in the problem you showed us, the line

protected int var = 1;

declares and initializes a member variable that is inherited by descendant classes. ('protected' means the variable is accessible to child types and to types in the same package.)

So in the 'GrandChild' class, the 'main()' method:

public static void main(String[] args) {
GrandChild gc = new GrandChild();
gc.var = 2;
Child c = new Child();
gc.test2();
}

'gc.test2()' and 'gc.var' refer to the same exact 'var' as 'super.var' because there is no difference between 'this.var' and 'super.var' inside 'GrandChild'.

Notice that the 'Child' declaration, 'Child c = new Child();', creates anunreferenced variable 'c'. Nothing uses 'c' - it's just allocated and garbage collected. The JVM very likely will not even allocate that object in any run of the program.