Fully groking the construction of a child object in memory.

[Grant Robertson]

I understand how to write a child object. I know what can access what and the order of execution of each statement, including fields, initialization blocks, and constructors. I know what will be inherited by the child and how private fields and methods are not inherited. I also know that private fields and methods in Parent are still accessible indirectly through constructors, and non-private methods. I know how to use super() and this() with or without parameters. I know when super() will be automatically inserted by the compiler and how the Object class will always be the ultimate parent class. However, I have not been able to find an explanation of exactly (or even approximately) how all this is actually put together into an actual object in memory.

For instance, if Parent.field is private and Parent.fieldGetter() is public then Child inherits fieldGetter() and can call it directly as if it is a member of Child. In fact other classes can call Child.fieldGetter() with no clue that it is not an actual member of Child. But, if fieldGetter() is now part of Child and Parent was never actually instantiated, then how is Parent.field available for Child.fieldGetter() to read? In fact, how does Parent.field exist at all? Where is it stored? (OK, I know, "on the heap.") But I want to know what it is associated with in memory. Is it treated like part of Child? Is there really a Parent object on the heap and Child simply contains references to the parts of Parent that it inherited? What?

If anyone has a link to a good explanation of all this, complete with diagrams, I would really appreciate it. Even if there is a passage in some book, I would like to know about that too. I have access to lots of Java books through the UT Austin library and other sources.

Thanks.

[Paul Clapham]

Try not to get the access rules (private, public etc) mixed up with the inheritance rules. In your example: A Child object is a Parent object, because Child extends Parent. You'll see this relationship described as "IS-A" when people are talking about inheritance, e.g. a Child IS-A Parent. And since a Child object is a Parent object, it contains the field named "field" from the Parent declaration. It's true that none of Child's code has access to that field, but it's there nevertheless.

As for where things are stored in memory: You're really not supposed to ask that question, because it's left up to the implementers of the JVM to decide that. The Java Language Specification just defines how the language works, not how it's implemented. However I'll say that a reasonable implementation of a JVM (i.e. one that I would write, ha ha) would keep all of Child's data members in the same place and not scatter them into one part for Child-only members, one part for Parent-only members, and one part for Object-only members (remember that Parent extends Object). So there's one block of memory which contains the members declared by Object, the members declared by Parent, and the members declared by Child.

I suppose an implementation which used three blocks of memory with pointers keeping them together would be conceivable (of course it IS conceivable because you already conceived of it), but it would use more memory and be harder to navigate and make garbage collection more difficult, which is why I think the actual JVM implementers and me are on the same page.

[Campbell Ritchie]

When you go on about Parent not being instantiated, so you mean can you have a superclass object not instantiated when a subclass object is created?

No, that breaches the rules of inheritance. When you call the subclass' constructor, that automatically calls the superclass's constructor and creates a superclass object. That object probably constitutes part of the subclass object, but as Paul C says, that is an implementation detail which is not specified. So you must have something which represents the superclass instance and where those superclass fields are stored.

[nick woodward]

But, if fieldGetter() is now part of Child and Parent was never actually instantiated, then how is Parent.field available for Child.fieldGetter() to read? In fact, how does Parent.field exist at all?

parent is instantiated because the child IS-A parent as others have said. in the same way that an object is instantiated too - not as a separate 'thing', but as the child itself.

i'm pretty sure the Head First Java book has a good description of this with diagrams. in fact i've just checked - page 214 'get in touch with your inner object'.

[Mike. J. Thompson]

Remember that whenever you run a constructor the first statement in the constructor will always be a call to super() (or an overloaded version of super with parameters). If you don't write the call to super() yourself it will be added in automatically by the compiler. It is never possible to construct an object without first constructing the parts inherited from the superclass.

[Grant Robertson]

Paul Clapham wrote:Try not to get the access rules (private, public etc) mixed up with the inheritance rules. In your example: A Child object is a Parent object, because Child extends Parent. You'll see this relationship described as "IS-A" when people are talking about inheritance, e.g. a Child IS-A Parent. And since a Child object is a Parent object, it contains the field named "field" from the Parent declaration. It's true that none of Child's code has access to that field, but it's there nevertheless.

Well, I know that Child IS-A Parent in that a Child object can be treated as a Parent object the reference to the Child object is assigned to a variable that is declared with a Parent datatype. However, being a Y which is treated as X does not mean that Y is truly constructed as an X with the unique Y parts added.

Paul Clapham wrote:As for where things are stored in memory: You're really not supposed to ask that question, because it's left up to the implementers of the JVM to decide that. The Java Language Specification just defines how the language works, not how it's implemented. However I'll say that a reasonable implementation of a JVM (i.e. one that I would write, ha ha) would keep all of Child's data members in the same place and not scatter them into one part for Child-only members, one part for Parent-only members, and one part for Object-only members (remember that Parent extends Object). So there's one block of memory which contains the members declared by Object, the members declared by Parent, and the members declared by Child.

I suppose an implementation which used three blocks of memory with pointers keeping them together would be conceivable (of course it IS conceivable because you already conceived of it), but it would use more memory and be harder to navigate and make garbage collection more difficult, which is why I think the actual JVM implementers and me are on the same page.

For simplicity of design, I would agree with you. However, as ALL objects inherit from Object that would mean an awful lot of copies of the parts of Object that are common to all classes being copied to all the other parts of the heap that store all those different classes. I do know that the JVM does not store a separate copy of all the methods and static fields for each separate object instantiated for a particular class. The JVM stores those parts only once with pointers pointing to where they are. Only the instance fields and local variables are stored separately. So, it may be reasonable to assume that the same system is used for the parts from parent classes which are inherited by child classes.

[Grant Robertson]

nick woodward wrote:parent is instantiated because the child IS-A parent as others have said. in the same way that an object is instantiated too - not as a separate 'thing', but as the child itself.

i'm pretty sure the Head First Java book has a good description of this with diagrams. in fact i've just checked - page 214 'get in touch with your inner object'.

Thanks, I took a look at my copy of Head First Java and this at least explains enough for me to now trust that all the parts of Parent are truly embedded within Child. Of course, now that I think of it, how could they not be and have polymorphism still work.

So, whether a particular JVM uses only one copy each of all these common parts with lots of pointers or an actual separate copy in each part of the heap reserved for the methods and static fields common to an entire class is now rather moot. All I need to care about is that ALL the parts of the Parent are treated as if they are embedded (however the JVM decides to do so) within the Child. It is just that either the compiler or the JVM treats the private parts of Parent as if they are not actually part of Child whenever Child is being accessed through a variable that is declared with the Child datatype. And that either the compiler or the JVM treats the private parts of Parent as accessible, and ignores the parts of the object that come from Child, whenever that object is accessed through a variable that has been declared with the Parent datatype.

I think I can call this question "Resolved."

Thanks,
Grant

P.S. The reason I did not see that description in my Head First Java book is that all the extra crap in those books drives me crazy. I have moderate Asperger's and I find it impossible to ignore all those stupid cartoons. So I stopped reading it and got a different book. OK, lots of different books. I'm also a picky-ass technical-writer and bad grammar or bad explanations also drive me nuts.

[Campbell Ritchie]

Well done sorting out the question

[nick woodward]

Grant Robertson wrote:

nick woodward wrote:parent is instantiated because the child IS-A parent as others have said. in the same way that an object is instantiated too - not as a separate 'thing', but as the child itself.

i'm pretty sure the Head First Java book has a good description of this with diagrams. in fact i've just checked - page 214 'get in touch with your inner object'.

Thanks, I took a look at my copy of Head First Java and this at least explains enough for me to now trust that all the parts of Parent are truly embedded within Child. Of course, now that I think of it, how could they not be and have polymorphism still work.

So, whether a particular JVM uses only one copy each of all these common parts with lots of pointers or an actual separate copy in each part of the heap reserved for the methods and static fields common to an entire class is now rather moot. All I need to care about is that ALL the parts of the Parent are treated as if they are embedded (however the JVM decides to do so) within the Child. It is just that either the compiler or the JVM treats the private parts of Parent as if they are not actually part of Child whenever Child is being accessed through a variable that is declared with the Child datatype. And that either the compiler or the JVM treats the private parts of Parent as accessible, and ignores the parts of the object that come from Child, whenever that object is accessed through a variable that has been declared with the Parent datatype.

I think I can call this question "Resolved."

Thanks,
Grant

P.S. The reason I did not see that description in my Head First Java book is that all the extra crap in those books drives me crazy. I have moderate Asperger's and I find it impossible to ignore all those stupid cartoons. So I stopped reading it and got a different book. OK, lots of different books. I'm also a picky-ass technical-writer and bad grammar or bad explanations also drive me nuts.

No problem, glad you've got it sorted!

I also found the HF book a little too much - I can see how it works for others, and obviously it was very effective RE: that diagram on page 214, but I'd agree it is a little intense!! On the flipside the OCA and OCP programmer study guide (also by KS & BB) has been one of the better books I've read so far.

You may enjoy C. Thomas Wu as an author. Very 'to the point' and quite an academic style - apparently a negative in most reviews, but something I like.

Regards,

Nick

[Grant Robertson]

nick woodward wrote:You may enjoy C. Thomas Wu as an author. Very 'to the point' and quite an academic style - apparently a negative in most reviews, but something I like.

Thanks, I will look him up.