What really happens on inheritance in Java?

Question

Suppose I have two classes Parent and Child, and Child inherits from Parent. I have three methods in Parent, out of which two are public and one is private.

Normally we say that all the non-private methods are inherited into the Child class, but I'm confused about exactly what happens. Does Java make a copy of the methods in the Child class, or does it use some kind of reference to maintain the relationship?

class Parent{
    // Private method
    private void method1(){
        System.out.println("In private method of Parent class");
    }
    void method2(){
    // calling private method
        method1();
    }
    void method3(){
    // calling private method
        method1();
    }
}

class Child extends Parent{

}

class MainClass{
   public static void main(String[] args){
       Child child = new Child();
       // calling non-private method which internally calls the private method
       child.method2();
   }
}

Answer 1

Does Java makes copy of the methods in the Child class or it uses some kind of reference to maintain the relationship?

Latter. Take a look at invokespecial. Java recursively looks up methods one class at a time. The first matching method is called. This is why calling a virtual (default) method is slower than calling a final method.

In general, the actual code within a method is not copied when you inherit from a class containing that method.

Answer 2

Neither.

Inheritance is a programming language concept, not a real action. When you investigate the compiled Child class, e.g. with javap, you won’t find any artifact related to the three methods of Parent. There will be the information that Child has the superclass Parent, but no mentioning of the inherited methods, neither as references nor as copies.

The fact that Child conceptionally inherits methods from Parent comes into play when you actually try to invoke one of them through a variable whose compile-time type is Child, like in your Test class. Then it is up to the compiler to find the inherited methods in order to compile the code containing the invocation correctly. It is also up to the compiler whether it searches the class hierarchy every time it resolves a target method of an invocation or whether it collects the existing methods in certain data structures to speed up subsequent lookups and which data structures it uses.

This process is more complicated than you might think. There may be multiple candidates among which the compiler has to select one and it may even fail due to ambiguity. The result of the process will be a decision about whether the invocation is valid and, in case it is valid, a single target method and its actual signature.

The compiled invocation will contain the name and signature of the target method and a reference to the compile time type of the reference on which it is invoked, i.e. Child. It will not contain the information that the actual method has been inherited from Parent. This is intentional. Whether Child declares the method itself, inherits it from Parent or overrides a method of Parent should not affect the code of the invoker Test nor the compatibility between compiled class files.

---

This implies that at runtime a class like Test may contain a reference, given by name and signature, to a method in Child not being stored in the class file of Child, in other words, the JVM is responsible as well, for making the concept of inheritance working. At the same time, it has to ensure that the concept of overriding works, when a method invocation is executed.

The way it implements this is also unspecified, leaving room for different strategies. Searching class hierarchies on every invocation would be legal, but lead to poor performance.

A common technique is a vtable. Associated with every class is a table (array) containing references to the available methods, be it declared or inherited. On initialization of a subclass, its table will start with a copy of the superclass’ table, having entries for new methods appended at the end and entries of overridden methods changed. At some time, the method invocation will be linked by finding the index of the vtable entry, appropriate to the specified name and signature. A typical strategy is to do the lookup on the first invocation. The instruction is then modified to refer to the index to avoid subsequent lookups. From then, subsequent executions consist of fetching the vtable for an object’s runtime class and getting the method reference from the table’s entry.

Considering that, you could say that at runtime, inheritance is typically implemented as some kind of reference—but wait.

Implementations like Oracle’s JVM are capable of doing hotspot optimizations in which the context of often executed code is considered. There might be, for example an inherited method which itself invokes methods which have been overridden in some subclasses. When the JVM finds out that this method is called very often on a single concrete subclass, it may create an optimized version for that particular case. Then, a copy of the method’s code will be the starting point for the subsequent code transformations, inlining code of the specific subclass, etc.

Since such sophisticated implementations will use references for non-optimized code while using optimized copies in other cases, an alternative to the initial answer answer could be:

Both.

Answer 3

Method bodies aren't copied in the undefined method body of a subclass. Instead, when you call

Child child1 = new Child();
child1.method1();

It will look through its hierarchy, going up a level every time it can't find an implementation. First it will check Child which has no implementation. One level above that there's Parent which does, so it will use that one.As correctly mentioned by @Dante above that this is achieved via the super() call in the constructor of the Child Class. This image might help you get a better picture :

I think your confusion is somehow associated to the point of non inheritance of the private methods.So,I would like to address that as well

Why Private Members are not inherited ?

You could say that private members are not inherited, because nowhere can Child refer explicitly to value. I.e. any code like this.value can't be used within Child, nor can obj.value be used from some calling code (obviously). However, in another sense, you could say that value is inherited. If you consider that every instance of Child is also an instance of Parent, then that object must contain 'value' as defined in Parent. Even if the Child class knows nothing about it, a private member name value still exists within each and every instance of Child. So in this sense, you could say that value is "inherited" in Child.So without using the word "inheritance", just remember that child classes don't know about private member defined within parent classes. But also remember that those private members still exists within instances of the child class.

Note: The the JLS states (http://docs.oracle.com/javase/specs/jls/se5.0/html/classes.html#8.2):

Members of a class that are declared private are not inherited by subclasses of that class. Only members of a class that are declared protected or public are inherited by subclasses declared in a package other than the one in which the class is declared.

Answer 4

Java does not make a copy of the methods.The methods that are inherited stay with the parent class only.

Now you must me wondering,How does child class get access to them?

The answer lies in understanding the super keyword.

The super keyword is used to refer to object of immediate parent class.The very first thing super does is initialize object of parent class.This means it is responsible for creating object of parent class and is used to refer to that object.

The super(); is implicitly the first statement inside constructor of child class,however you can do that explicitly also.

Now the important part:

If you have the following:

super();

not as your first statement inside child class constructor,then compile error is generated saying:

call to super must be first statement in constructor.

The reason is:

Because the child class is assumed to have the inherited methods,but do not possess a copy of them.

The inherited methods are basically with parent class,so it is important to create object of parent class first,so that whenever following is used

instance_of_child.method_of_parent();

The method will be actually invoked from object of parent class,which was already created by super(explicitly or implicitly used).

This is the reason why you can have child class constructor like:

Child()
{
 super();
 parent_method();
}

but not like:

Child()
{
 parent_method();
 super();
}

because parent_method(),that is the inherited method requires reference to object of parent class which is provided by super().