Hidden fields though inheritance

Question

In the following code example:

class Parent { 
    int x =5;
    public Integer aMethod(){

        System.out.print("Parent.aMthod ");
        return x;
    }
}

class Child extends Parent {
    int x =6;
    public Integer aMethod(){
        System.out.print("Child.aMthod "); 
        return x;
    }
}


class ZiggyTest2{

    public static void main(String[] args){

        Parent p = new Child();
        Child c = new Child();

        System.out.println(p.x + " " + c.x);

        System.out.println(p.aMethod() + "  \n");
        System.out.println(c.aMethod() + "  \n");
    }   
}

And the output:

5 6
Child.aMthod 6  

Child.aMthod 6

Why does p.aMethod() not print 6 when p.x prints 6?

Thanks

Edit

Oops a slight typo: The question should be "why does p.aMethod() not print 5 when p.x print 5" - Thanks @thinksteep

Wailoo

I think your question should be "why does p.aMethod() not print 5 when p.x print 5? – Clothe

The language should forbid variable hiding; I cannot see any application except bugs. It should also forbid static method hiding. – Chuckhole

@toto2, perhaps that would be better. Shadowing is already forbidden for nested scopes (with the exception of class scope vs method scope). – Mareah

Thank you all for your responses. – Wailoo

Answer 1

There's no polymorphic resolution being done when you access class member fields (instance variables) like p.x. In other words, you'll get the results from the class that's known at compile time, not what is known at run time.

For method calls this is different. They are dispatched at run time to an object of the actual class the reference points to, even if the reference itself has a super type. (in the VM this happens via the invokevirtual opcode, see e.g. http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc6.html#invokevirtual).

Mareah

When talking on the bytecode level the bytecode for getting the field values should not be omitted. It is getfield (see JVM-Spec) – Supersonic

Answer 2

Operations are always on Objects. In both cases, p.aMethod() and c.aMethod(), object is child that is why it printed 6 in both cases. When you directly access variable directly it reads variable associated with left side.

Clothe

Answer 3

Because declaring a variable doesn't inherit. You have two copies of x in the class, one in parent namespace, one in child namespace.

Tiresias

Not quite. Member variables are inherited, but they don't act polymorphically. – Equiprobable

compare the result of this.x and super.x - both are available to the subclass. This is called shadowing. – Squab

So they are inheritted when the sub class doesn't declares one of its own. If it does, the super version will be shadowed instead of overriden. Funny when you think of it. – Brennen