• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Devaka Cooray
Saloon Keepers:
  • Ganesh Patekar
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
Bartenders:
  • Ron McLeod
  • Frits Walraven
  • Pete Letkeman

Overriden method, supertype reference  RSS feed

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,
This is my first post on this forum so Hello Everyone!
Currently I'm preparing for the SCJP exam 310-065 with a K&B book. Now I'm studying on Overriden methods and on the page 108 there's written "If a method is overriden but you use a polymorphic (supertype) reference to refer to the subtype object with the overriding method, the compiler assumes you're calling the supertype version of the method". As far as I understand the following code:

Should produce:
sss
maaaow

b1 is a supertype reference and we refer to a subtype with it. And for some reason I get:
maaaow
maaaow

Altough when I follow the book further, there's an example with throwing exception:

And in this case, the code doesn't compile -

Cat.java:14: unreported exception java.lang.Exception; must be caught or declare
d to be thrown
b1.suck();
^
1 error


So it seems that now, the compiler looks at the supertype method as it was written in the book before. But why it behaves so differently?
Cheers,
Jan.
 
Ranch Hand
Posts: 338
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually... the compiler doesn't know that the b1 is actually a Cat... it knows it to be of type Being (even though we know it to be a Cat)... so it requires you to enclose b1's suck method within a try/catch block because the compiler knows that Being.suck() throws an Exception.

At run time, Java knows that the b1 Being object is in fact a cat and will show "maaaow" for b1.suck() and "maaaow" for b2.suck().

I'm sure some of the others can give a more eloquent explanation... but that is what actually happens.
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hellom Jan Stefaniuk,

I've just registered this forum by now as I noticed it can help me studing for SCJP.
I've finished the chapter that covers your doubt, so I´ll give a try to that. Please, anyone, if I'm wrong tell me.

The code you gave as an example:



The type of the reference itself determines the methods it can invoke. So, as the reference b1 is of type Being it can only invoke the suck() method of the Being class. This is what the compiler knows! And, as far as it (compiler) knows, the suck() method of the Being class throws a checked exception that must be caught or declared to be throw. That explains the error you get. Remember that it's only at compiler time!

However, we know that Cat is a subclass of Being so that it inherits it's superclass methods. We also know that Cat overrides suck() method.

We already know why we got the compiler error and now we can treat that. Just code a try... catch block to solve this problem.



Now it compiles!

And, which suck() method will it call? Now polymorphim gets to work.
At runtime, although b1 is of type Being, it refers to an object of type Cat and, as polymorphim works for overriding, it calls the suck() method of Cat instance.

Well, that´s it. I think.
 
Jan Stefaniuk
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, thanks, now it's more clearer. So it's the matter of compile/run time. But anyway, why such a thing is not solved during the compile time? I mean the compiler can see that in fact b1 refers to the Cat object.
Cheers, Jan
 
Paul Campbell
Ranch Hand
Posts: 338
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan Stefaniuk wrote:Ok, thanks, now it's more clearer. So it's the matter of compile/run time. But anyway, why such a thing is not solved during the compile time? I mean the compiler can see that in fact b1 refers to the Cat object.
Cheers, Jan




this is because java implements "late binding" to support polymorphism. keep in mind this does not apply to static or final methods. it also does not apply to variables you reference directly.
 
Guilherme Bazilio
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan Stefaniuk wrote:
I mean the compiler can see that in fact b1 refers to the Cat object.



I don't think the compiler knows that. I think it sees only the reference type, not the instance type.

;P
 
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it would be worth emphasising in the book that there's a difference between what the compiler
thinks is happening and what happens at runtime. This confused me for a good hour. Great book though.
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By the way, both methods shouldn't compile because they are the same. Or is it me who is blind

Bob
 
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bob Wheeler wrote:Or is it me who is blind Bob


No you are not blind, you just need to know overriding.......
A subclass inherits accessible methods from its super class.
If the subclass declares its own version of the method, ie. same signature , it overrides the superclass method.
So, its not an error and should compile.
 
Bob Wheeler
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Sachin Adat wrote:

Bob Wheeler wrote:Or is it me who is blind Bob


No you are not blind, you just need to know overriding.......


I do, I do. At least I think so.

Sachin Adat wrote:
A subclass inherits accessible methods from its super class.
If the subclass declares its own version of the method, ie. same signature , it overrides the superclass method.
So, its not an error and should compile.



It doesn't compile here. But that was already stated above.
I quote:

Guilherme Bazílio wrote: And, as far as it (compiler) knows, the suck() method of the Being class throws a checked exception that must be caught or declared to be throw. That explains the error you get. Remember that it's only at compiler time!

 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!