method overriding

Question

class A
{
  int i=10;
  void show()
  {
    System.out.println("class A");
  }
}

class B extends A
{
  int i=5;
  public void show()
  {
    System.out.println("class B");
  }
}
class M
{
  public static void main(String s[])
  {
    A a=new B();
    a.show();
    System.out.println(a.i);
  }
}


OUTPUT= class B
        10

If class A method is overridden by class B method then why not the variable 'i'?

Answer 1

Because variables are not virtual, only methods are.

Answer 2

Because by default the variables are private. You must declare it as "protected", then will be properly inherited.

Answer 3

It is not overwritten, but hidden. In your output you specifically requested the value of a.i, not ((B)a).i.

Answer 4

a is an instance of A. You call the constructor B(). But it is still a A class. That is why i equals 10; The override from the method will be succeded.

Note a class starts not with

public class A()

but with;

public class A { ... }

Answer 5

Instead of:

A a=new B();

Try:

B b = new B();

A a = b;

Answer 6

This is a "feature" of the implementation. In memory, this looks like so:

a:
    pointer to class A
    int i

b:
    pointer to class B
    int i (from A)
    int i (from B)

When you access i in an instance of B, Java needs to know which variable you mean. It must allocate both since methods from class A will want to access their own field i while methods from B will want their own i (since you chose to create a new field i in B instead of making A.i visible in B). This means there are two i and the standard visibility rules apply: Whichever is closer will win.

Now you say A a=new B(); and that's a bit tricky because it tells Java "treat the result from the right hand side as if it were an instance of A".

When you call a method, Java follows the pointer to the class (first thing in the object in memory). There, it finds a list of methods. Methods overwrite each other, so when it looks for the method show(), it will find the one defined in B. This makes method access fast: You can simply merge all visible methods in the (internal) method list of class B and each call will mean a single access to that list. You don't need to search all classes upwards for a match.

Field access is similar. Java doesn't like searching. So when you say B b = new B();, b.i is obviously from B. But you said A a = new B() telling Java that you prefer to treat the new instance as something of type A. Java, lazy as it is, looks into A, finds a field i, checks that you can see that field and doesn't even bother to look at the real type of a anymore (because that would a) be slow and b) would effectively prevent you from accessing both i fields by casting).

So in the end, this is because Java optimizes the field and method lookup.

Answer 7

It's a design decision by the developers of Java, and is documented in the Java Language Specification.

A method with the same method signature as a method in its parent class overrides the method in its parent class.

A variable with the same name as a variable in its parent class hides the parent's variable.

The difference is that hidden values can be accessed by casting the variable to its parent type, while overridden methods will always execute the child class's method.

As others have noted, in C++ and C#, to get the same override behavior as Java, the methods need to be declared virtual.

Answer 8

Tip: You can use setters and getters to make sure of what data-members you use.
Or: You simply can set the values at the constructor instead of the class declaration.

Answer 9

Why no field overrides in Java though?

Well, because instance field lookups in Java happen at compile time: Java simply gives you the value of the field at a given offset in object's memory (based on the type information at hand during compilation: in this case a is declared to be of type A).

void foo() {
  A a = new B();
  int val = a.i; // compiler uses type A to compute the field offset
}

One may ask "Why didn't compiler use type B since it knows that a is in fact an instance of B? Isn't it obvious from the assignment just above?". Of course, in the case above, it's relatively obvious and compiler may try to be smarter and figure it out.

But that's compiler design "rat hole", what if a "trickier" piece of code is encountered, like so:

void foo(A a) {
  int val = a.i;
}

If compiler were "smarter", it would become its job to look at all invocations of foo() and see what real type was used, which is an impossible job since compiler can not predict what other crazy things may be passed to foo() by unknown or yet unwritten callers.