• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Super's variable, sometimes!

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Just trying to improve my understanding of inheritance and access to a super class's variable, I wrote 3 classes and came across something I do not understand. It seems that if a class refers to its super's variable explicitly, via super., then later use of that variable's name continues to refer to the super's variable, even without the 'super.'.
If no 'super.' is ever used, reference is to the sub-class's copy ... ?
Any ideas where I'm getting this wrong would be appreciated.

Here's the code & output:
-------------------------------------

-------------------------------------------

---------------------------------------------

-----------------------------------------------------
-----------------------------------------------------
Output:
new Junk starting
junk Constructor says b equals 5
junkSay says b equals 5
new TJ1 starting
junk Constructor says b equals 5
null says entered Constructor now
TJ1 says exiting Constructor now
TJ1 says added 100 to super.b: 105
junkSay says b equals 105
TJ1 says added 1 to my b: 106
junkSay says b equals 106
new TJ2 starting
junk Constructor says b equals 5
null says entered Constructor now
TJ2 says exiting Constructor now
TJ2 says not added 100 to super.b: 5
junkSay says b equals 5
TJ2 says added 1 to my b: 6
junkSay says b equals 6
-----------------------------------------------

[edit]Add code tags. CR[/edit]
[ January 01, 2009: Message edited by: Campbell Ritchie ]
 
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to JavaRanch

The subclass does not have a "copy" of the superclass field; in fact the fields ought to have private access, so direct access to the field with super.x should be impossible. If access is required, you can use a get method. You remember that a subclass field hides the superclass field of the same name.

But you haven't got a superclass field and a subclass field of the same name; you only have "b". You can get access to "b" with the super keyword, or without, from a subclass or any other class in the same package. (I bet you have been told that protected access is confined to subclasses!) So you only have one "b." If you had a subclass field with the same identifier, you could get even worse confusion, as you can see in this recent thread. In which case you could get access with super. or without super. but they would be different fields from different classes.

You have 5, you add 100 to it, or you add 1 to it, and get 105 or 6. And you get "null" printed for the name field; I presume you know why.
 
Ranch Hand
Posts: 2908
1
Spring Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As there is single copy of 'b' instance variable, the super.b or simply b refers to same object .. But If you hide the super class 'b' instance by providing your own 'b' varibale, then you need to explicitly told the compiler which 'b' you are referring, with or without 'super' keyword..

Just have modified code which you posted early ..

 
Michael Russell
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the replies. I've realised I was thinking the in-memory structure was:

TestUseJunk
v
Junk
/ \
tJ1 tJ2
and that tJ1 & tJ2 had access to junk.b, which existed only once.
What was really the case was:

TestUseJunk
v v v
Junk tJ1 tJ2
and tJ1 & tJ2 were accessing their own uninstantiated super class's b.
You can also see this because Junk's constructor is called thrice (not just once): for j1 and when tJ1 and tj2 are instantiated.

I hope that looks right .....
 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you are correct, but don't go thinking the superclass is uninstantiated. There is a copy of that "b" in memory somewhere, which means that there is memory which corresponds to the superclass somewhere. So some part of your object actually represents the superclass object. I don't know whether it is the same memory location as the superclass object, or a different location.
 
Michael Russell
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good point: thanks, Campbell.
 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome
 
reply
    Bookmark Topic Watch Topic
  • New Topic