Where do private fields of super class live when accessed from sub class using public getter?

Question

not to be stated as duplicate this question address where the field lives in the program not is it inherited or not or if it inherited but not accessible.

please continue reading to understand

in the example below we see that the dog object can access the animal private field "name" throw the use of a public getter "getName" but is not the private fields are not inherited so where the field name is living

from searching i realized that only one object is created from the sub class and not two one to the sub and one to the super to hold the private fields.

focus now >> we all know that a public setter in any class can set its private fields but we know where the field is living ! in the object of the class

so my question in abstract is as follow

where the accessed private field is living in the sub class created object !

Where is it !

public class Animal {
    private String name ;
    public Animal (String name)
    {
        this.name = name;
    }

    public String getName()
    {
        return this.name;
    }
}

public class Dog extends Animal {

    public Dog(String name) {
        super(name);
    }
}

public class Hello {
    public static void main(String[] args) {
        Dog mmms = new Dog("mmkk");
        System.out.println(mmms.getName());
    }
}

edit : i think this question may be stated as

where does the private fields of the parent class live if it is not inherited ?

question name changed for more understanding from

How the sub Class object get access to the private members of its super class from public getters?

to

Where do private fields of super class live when accessed from sub class using public getter ?

Answer 1

Whenever an instance of a subclass is created, that is an instance of Dog in this case, constructors of all parent classes are called in a sequence allocating space required to store the state of the complete chain. In your case the super constructor is called explicitly, but even in an absence of an explicit call, an implicit call will be made provided there is a default constructor (if not then the code won't compile).

Information about the state of the parent instance state(s) is available and stored with the instance of the child. The way this information is stored depends on the JVM implementation with Oracle JRE being different from OpenJRE. However, it does not matter, that matter is that the child may not have access to fields or methods of the parent (in case of private fields or methods), but all fields are present and allocated a value, at least a default one. All methods are also present and are dispatched over based on vtable:

Instance methods are dispatched to those parts of the instance that correspond to the defining class. So if, in your case the class Animal defines getName and setName an no parent en-route to Dog redefines them, the JRE will execute the code with the state maintained by the part corresponding to Animal, thus setting or retrieving the name stored there. At the same time, all Java methods (including private), are virtual and, thus, can be overridden in subclasses. The information about such overrides will be persisted in the vtable responsible for dispatching. So if your class Dog redefines the getName and setName to do something else (it will not be able to access the field name from that class definition), then calling those methods on an instance of Dog will actually invoke methods defined in Dog rather than Animal. In this case you will likely lose any access to the field name within Animal (unless there are other getters/setters defined in Animal) even though the value that you put there in the constructor will remain stored.

As indicated elsewhere, one can still access private information via reflection or bytecode manipulation, but this would be done either rarely or for a very particular reason (e.g. the @Inject annotation on private fields is likely to result in setting a value via some injection framework). Even though this can be done, accessing private hidden (private, protected, package visible) methods or fields via reflection should be an exception rather than common practice as it obviously violates the original design decision.

Further reading:

• https://en.wikipedia.org/wiki/Virtual_method_table
• Virtual table/dispatch table
• Why does OpenJDK place private methods into vtable?

Answer 2

There is only one instance of Dog which contains also the name instance variable because a Dog is an Animal and despite the fact that the field is not properly inherited from the parent class it is present in the instance.

What disturbs you is the fact that name isn't directly accessible from Dog code but it is there. It is just made to preserve encapsulation.

You can however read or modify this value by using a public or protected method of Animal, as getName() does or you can use reflection to achieve this goal:

Dog dog= new Dog("mmmk");
Field name = Animal.class.getDeclaredField("name");
name.setAccessible(true);
name.set(dog, "xxxxx");
System.err.println(dog.getName());

Now you can see that name's value has been modified to "xxxxx"