Parent sample = new Child();
sample.childMethod(); // error
sample.parentMethod(); // ok
(Child)sample.childMethod(); // ok
I roughly know why above code works like that. Because sample is declared as a Parent type, Java thinks sample has the Parent attribute even it has Child’s instance.
And someone gave me a nice analogy like below:
remote – TV analogy: you have a TV with multiple functions, like browsing TV channels, YouTube, Netflix. However, your remote can only browse TV channels.
Still, I wonder how Java knows the type of variable which actually has the sub type instance’s reference.
If I declare the reference type variable and assign sub type instance to it, as I studied, the instance data is stored in heap area and its reference is stored in stack area.
However, it cannot make me understand how Java knows sample‘s data type and use it.
Is the variable’s type information stored in stack area as well?
>Solution :
It’s more complicated than I’m about to make it out to be, but for this purpose we can assume type information is mostly absent at runtime, and is used mostly at compile-time.
The error you get when you try to write
sample.childMethod()
is a compile-time error, not a runtime error. When the compiler is looking at the code, it checks what type sample is (Parent), sees that Parent.childMethod() is not defined, and then stops trying to compile the code until you fix what it sees as a problem.
Typecasting (((Child) sample).childMethod()) tells the compiler that "hey I’m going to try to treat this object as though it were a member of a different class". Then, only when actually executing the typecast, the JVM will compare the new class (Child) to the instance and determine whether or not the instance has all the required methods and attributes. If it fails this check, you’ll get a ClassCastException, not a NoSuchMethodError.
You will also note that ClassCastException is a runtime exception, whereas NoSuchMethodError is a checked error. This indicates that it’s supposed to only be thrown during compilation, not catching a problem during runtime (and indeed, you will almost never see a NoSuchMethodError thrown at runtime unless you’re doing something really funky with the reflection API).