wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Super's variable, sometimes! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Super Watch "Super New topic
Author

Super's variable, sometimes!

Michael Russell
Greenhorn

Joined: Jan 01, 2009
Posts: 3
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 ]

Regards,<br /> <br />Michael
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38003
    
  22
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.
Sagar Rohankar
Ranch Hand

Joined: Feb 19, 2008
Posts: 2902
    
    1

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 ..



[LEARNING bLOG] | [Freelance Web Designer] | [and "Rohan" is part of my surname]
Michael Russell
Greenhorn

Joined: Jan 01, 2009
Posts: 3
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
Sheriff

Joined: Oct 13, 2005
Posts: 38003
    
  22
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

Joined: Jan 01, 2009
Posts: 3
Good point: thanks, Campbell.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38003
    
  22
You're welcome
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Super's variable, sometimes!
 
Similar Threads
initialization sequence
Doubt in join().....
instance initializers
a confusion question!
polymorphism question