Why is an instance variable of the superclass not overridden by a subclass?
You may refer following section / examples in Java language specification that explains about the topic.
- Example 8.3.1.1-3. Hiding of Instance Variables
- Section 8.4.8. Inheritance, Overriding, and Hiding and related examples
Rest of my post is an additional information for those who are interested in scratching the surface of jvm internals on this subject. We can start by examining the byte codes generated for class A using javap. Following disassembles the byte codes into a human readable text based instructions (mnemonics).
javap -c A.class
Without getting lost in many details of the entire dis-assembly, we can focus on the lines corresponding to b.print and b.a
9: invokevirtual #4 // Method B.print:()V
...
...
16: getfield #6 // Field B.a:I
We can immediately infer that the op codes used for accessing the method and a variable are different. If you are from a C++ school, you could sense that all method calls are virtual by default in java.
Now let us write another class A1 identical to A, but just has a casting for accessing variable 'a' in C.
public class A1 {
public static void main(String[] args) {
B b=new C();
b.print(); //casting is irrelevant here because methods are anyway bound at runtime System.out.println(((C)b).a);// the casting allows us to access of value of a in C
}
}
Compile the file and disassemble the class.
javap -c A1.class
You would notice that dis-assembly now points to C.a instead of B.a
19: getfield #6 // Field C.a:I
if you want to dig deep into this, here goes additional information:
- invokevirtual corresponds to opcode 0xb6
- getfield corresponds to opcode 0xb4
You can find a JVM specification that explains comprehensively about these opcodes at - http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html
Check out in amazon.com for "Java Virtual Machine" books that could make life little more easier for decoding the specification.
Why instance variable of a superclass is not overridden in subclass method see my code below ...
Because instance variables CANNOT be overridden in Java. In Java, only methods can be overridden.
When you declare a field with the same name as an existing field in a superclass, the new field hides the existing field. The existing field from the superclass is still present in the subclass, and can even be used ... subject to the normal Java access rules.
(In your example, an instance of C
has two distinct fields called a
, containing distinct values.)
Because instance variables CANNOT be overridden in Java, but why? why is it done in this manner in Java? What's the reason?
Why did they design it that way?
Because overriding variables would fundamentally break code in the superclass. For example, if an override changes the variable's type, that is likely to change the behavior of methods declared in the parent class that used the original variable. At worst, it renders them uncompilable.
For example:
public class Sup { private int foo; public int getFoo() { return foo; } } public class Sub extends Sup { private int[] foo; ... }
If
Sub.foo
overrides (i.e. replaces)Sup.foo
, how cangetFoo()
work? In the subclass context, it would be trying to return a value of a field of the wrong type!If fields that were overridden were not private, it would be even worse. That would break the Liskov Substitutability Principle (LSP) in a pretty fundamental way. That removes the basis for polymorphism.
On the flipside, overriding fields would not achieve anything that cannot be done better in other ways. For example, a good design declares all instance variables as private and provides getters/setters for them as required. The getters/setters can be overridden, and the parent class can "protect" itself against undesirable overrides by using the private fields directly, or declaring the getters/setters
final
.
References:
- Java Tutorial - Hiding Fields
- JLS Example 8.3.1.1-3 - Hiding of Instance Fields.