In a previous article Everything About ClassNotFoundException Vs NoClassDefFoundError, I have explained ClassNotFoundException and NoClassDefFoundError in details and also discussed their differences and how to avoid them. If you have not read it, please go ahead and give it a look.

Similar to that here in this article, we will look into one more core concept of Java which is method overloading and overriding. As soon as we start learning Java we get introduced to them and their contracts which are pretty simple to understand but sometimes programmers get confused between them or they do not know either it is a correct overload/override because of the different rules.

Here we will discuss What is method overloading and overriding, What contract one must follow to correctly overload or override a method, What are the different rules of method overloading and overriding and what are the differences between them.

Method Overloading

Method overloading means providing two separate methods in a class with the same name but different arguments while method return type may or may not be different which allows us to reuse the same method name.

And this becomes very handy for the consumer of our class, he can pass different types of parameters to the same method (in his eyes but actually they are different) and get the response according to his input e.g. System.out.println() method accepts all types of objects primitive types and print them but in reality there several println present in the PrintStream class.

public class PrintStream {

    // other methods

    public void println() { /*code*/ }
    public void println(boolean x) { /*code*/ }
    public void println(char x) { /*code*/ }
    public void println(int x) { /*code*/ }
    public void println(long x) { /*code*/ }
    public void println(float x) { /*code*/ }
    public void println(double x) { /*code*/ }
    public void println(char x[]) { /*code*/ }
    public void println(String x) { /*code*/ }
    public void println(Object x) { /*code*/ }
    
    // other methods
}

While overloading has nothing to deal with polymorphism but Java programmers also refer method overloading as Compile Time Polymorphism because which method is going to get called will be decided at compile time only.

In the case of method overloading compiler decides which method is going to get called based on the reference on which it is getting called and the method name, return type, and argument list.

class Human {
    public String speak() { return "Hello"; }

    // Valid overload of speak
    public String speak(String language) {
        if (language.equals("Hindi")) return "Namaste";
        else return "Hello";
    }

    public long calculate(int a, long b) { return a + b; }

    // However nobody should do it but Valid overload of calculate
    // by just changing sequence of arguments
    public long calculate(long b, int a) { return a + b; }
}

Method Overloading Rules

There are some rules which we need to follow to overload a method and some of them are mandatory while some are optional.

Two methods will be treated as Overloaded if both follow below mandatory rule.

• Both must have same method name
• Both must have different argument lists

And if both methods follow above mandatory rules then they may or may not

• Have different return types
• Have different access modifiers
• Throw different checked or unchecked exceptions

Usually, method overloading happens inside a single class but a method can also be treated as overloaded in the subclass of that class because subclass inherits one version of the method from the parent class and then can have another overloaded version in its class definition.

Method Overriding

Method Overriding means defining a method in the child class which is already defined in the parent class with same method signature i.e same name, arguments and return type (after Java 5 you can also use a covariant type as return type).

Whenever we extend a superclass in a child class, child class automatically gets all the methods defined in the super and we call them derived methods. But in some cases we do not want some derived methods to work in a manner which they are doing in the parent then we can override those methods in child class e.g. we always override equals, hashCode and toString from Object class, you can read more on Why can't we override clone() method from Object class.

In case of abstract methods either from a parent abstract class or interface we do not have any option we need to implement or in other words override all the abstract methods.

Method overriding is also known as Runtime Polymorphism and Dynamic Method Dispatch because which method is going to get called is decided at runtime by JVM.

abstract class Mammal {
    // Well might speak something
    public String speak() { return "ohlllalalalalalaoaoaoa"; }
}

class Cat extends Mammal {
    @Override
    public String speak() { return "Meow"; }
}

class Human extends Mammal {
    @Override
    public String speak() { return "Hello"; }
}

Using @Override annotation on the overridden methods is not necessary but using it will tell you if you are not obeying overriding rules. 

Mammal mammal = new Cat();
System.out.println(mammal.speak()); // Will print Meow

At the line mammal.speak() compiler says the speak() method of reference type Mammal is getting called, so for compiler this call is Mammal.speak().

But at the execution time JVM knows clearly that mammal reference is holding the reference of object of Cat, so for JVM this call is Cat.speak(). You can read more on How Does JVM Handle Method Overloading and Overriding Internally.

Method Overriding Rules

Similar to method overloading we also have some mandatory and some optional rules which we need to follow to override a method.

With respect to the method it overrides, the overriding method must follow below mandatory rule.

• It must have same method name
• Must have same arguments.
• Must have the same return type, from Java 5 the return type can also be a subclass (Subclass is a covariant type to its parent).
• Must not have a more restrictive access modifier (if parent --> protected then child --> private is not allowed).
• Must not throw new or broader checked exceptions.

And if both overriding methods follow above mandatory rules then it

• May have a less restrictive access modifier (if parent --> protected then child --> public is allowed).
• May throw fewer or narrower checked exceptions or any unchecked exception.

Apart from above rules, there are also some facts

• Only inherited methods can be overridden, Means methods can be overridden in child class only.
• Constructors and private methods are not inherited so cannot be overridden.
• Abstract methods must be overridden by the first concrete (non-abstract) subclass.
• final methods cannot be overridden.
• A subclass can use super.overridden_method() to call the superclass version of an overridden method.

Difference Between Method Overloading and Method Overriding

You can find complete code on this Github Repository and please feel free to provide your valuable feedback.

Continue reading

In my previous article Everything About Method Overloading Vs Method Overriding, I have discussed method overloading and overriding, their rules and differences.

In this article, we will see How Does JVM Handle Method Overloading And Overriding Internally, how JVM identifies which method should get called.

Let’s take the example of a parent class Mammal and a child Human classes from our previous blog to understand it more clearly.

public class OverridingInternalExample {

    private static class Mammal {
        public void speak() { System.out.println("ohlllalalalalalaoaoaoa"); }
    }

    private static class Human extends Mammal {

        @Override
        public void speak() { System.out.println("Hello"); }

        // Valid overload of speak
        public void speak(String language) {
            if (language.equals("Hindi")) System.out.println("Namaste");
            else System.out.println("Hello");
        }

        @Override
        public String toString() { return "Human Class"; }

    }

    //  Code below contains the output and and bytecode of the method calls
    public static void main(String[] args) {
        Mammal anyMammal = new Mammal();
        anyMammal.speak();  // Output - ohlllalalalalalaoaoaoa
        // 10: invokevirtual #4 // Method org/programming/mitra/exercises/OverridingInternalExample$Mammal.speak:()V

        Mammal humanMammal = new Human();
        humanMammal.speak(); // Output - Hello
        // 23: invokevirtual #4 // Method org/programming/mitra/exercises/OverridingInternalExample$Mammal.speak:()V

        Human human = new Human();
        human.speak(); // Output - Hello
        // 36: invokevirtual #7 // Method org/programming/mitra/exercises/OverridingInternalExample$Human.speak:()V

        human.speak("Hindi"); // Output - Namaste
        // 42: invokevirtual #9 // Method org/programming/mitra/exercises/OverridingInternalExample$Human.speak:(Ljava/lang/String;)V
    }
}

We can answer this answer in two ways, Logical way and Physical way, let's take a look at the logical way.

Logical Way

Logically we can say, during compilation phase calling method is considered from the reference type. But at execution time method will be called from the object which the reference is holding.

For Example on humanMammal.speak(); line compiler will say Mammal.speak() is getting called because humanMammal is of type Mammal . But during execution, JVM knows that humanMammal is holding a Human's object so Human.speak() will get called.

Well, it is pretty simple until we keep it at the conceptual level only. Once we get the doubt that how JVM is handling all this internally? or how JVM is calculating which method it should call.

Also, we know that overloaded methods are not called polymorphic and get resolved at compile time and this is why sometimes method overloading is also known as compile time polymorphism or early/static binding.

But overridden methods get resolved at runtime time because the compiler does not know that, the object which we are assigning to our reference have overridden the method or not.

Physical Way

In this section, we will try to find out physical proof of all aforementioned statements and to find them we will read the bytecode of our program which we can do by executing javap -verbose OverridingInternalExample. By using -verbose option we will get the descriptive bytecode same as our Java program.

Above command shows the bytecode in two sections

1. Constant Pool: holds almost everything which is necessary for our program’s execution e.g. method references (#Methodref), Class objects ( #Class ), string literals ( #String ), please click one image to zoom.




2. Program’s Bytecode: executable bytecode instructions, please click one image to zoom.

Why Method overloading is called static binding

In the above mention code humanMammal.speak() compiler will say speak() is getting called from Mammal but at execution time it will be called from the object which humanMammal is holding, which is the object of the Human class.

And by looking at the above code and images we can see that the bytecodes of humanMammal.speak() , human.speak() and human.speak("Hindi") are totally different because the compiler is able to differentiate between them based on the class reference.

So in the case of method overloading compiler is able to identify the bytecode instructions and method’s address at compile time and that is why it is also known as static binding or compile time polymorphism.

Why Method overriding is called dynamic binding

Bytecode for anyMammal.speak() and humanMammal.speak() are same ( invokevirtual #4 // Method org/programming/mitra/exercises/OverridingInternalExample$Mammal.speak:()V ) because according to compiler both methods are called on Mammal reference.

So now the question comes if both method calls have same bytecode then how does JVM know which method to call?

Well, the answer is hidden in the bytecode itself and it is invokevirtual instruction, according to JVM specification

invokevirtual invokes an instance method of an object, dispatching on the (virtual) type of the object. This is the normal method dispatch in the Java programming language.

JVM uses the invokevirtual instruction to invoke Java equivalent of the C++ virtual methods. In C++ if we want to override one method in another class we need to declare it as virtual, But in Java, all methods are virtual by default (except final and static methods) because we can override every method in the child class.

Operation invokevirtual accepts a pointer to method reference call ( #4 an index into the constant pool)

invokevirtual #4   // Method org/programming/mitra/exercises/OverridingInternalExample$Mammal.speak:()V

And that method reference #4 again refers to a method name and Class reference

#4 = Methodref   #2.#27   // org/programming/mitra/exercises/OverridingInternalExample$Mammal.speak:()V
#2 = Class   #25   // org/programming/mitra/exercises/OverridingInternalExample$Mammal
#25 = Utf8   org/programming/mitra/exercises/OverridingInternalExample$Mammal
#27 = NameAndType   #35:#17   // speak:()V
#35 = Utf8   speak
#17 = Utf8   ()V

All these references combinedly used to get a reference to a method and class in which the method is to be found. This is also mentioned in JVM Specification

The Java virtual machine does not mandate any particular internal structure for objects 4.

And the bookmark 4 states

In some of Oracle’s implementations of the Java virtual machine, a reference to a class instance is a pointer to a handle that is itself a pair of pointers: one to a table containing the methods of the object and a pointer to the Class object that represents the type of the object, and the other to the memory allocated from the heap for the object data.

It means every reference variable holds two hidden pointers

1. A pointer to a table which again holds methods of the object and a pointer to the Class object. e.g. [speak(), speak(String) Class object]
2. A pointer to the memory allocated on the heap for that object’s data e.g. values of instance variables.

But again the question comes, how invokevirtual internally do this? Well, no one can answer this because it depends on JVM implementation and it varies from JVM to JVM.

And from the above statements, we can conclude that an object reference indirectly holds a reference/pointer to a table which holds all the method references of that object. Java has borrowed this concept from C++ and this table is known by various names which such as virtual method table ( VMT ), virtual function table (vftable), virtual table (vtable), dispatch table.

We can not sure of how vtable is implemented in Java because it is JVM dependent. But we can expect that it will be following the same strategy as C++ where vtable is an array like structure which holds method names and their references on array indices. And whenever JVM tries to execute a virtual method it always asks the vtable for it address.

There is only one vtable per class, which means it is unique and same for all objects of a class similar to Class object. I have discussed more on Class object in my articles Why an outer Java class can’t be static and Why Java is Purely Object-Oriented Language Or Why Not.

So there is only one vtable for Object class which contains all 11 methods (if we don't count registerNatives) and references to their respective method bodies.



When JVM loads the Mammal class into memory it creates a Class object for it and creates a vtable which contains all the methods from the vtable of Object class with the same references (Because Mammal is not overriding any method from Object) and adds a new entry for speak method.




Now here comes the turn of Human class and now JVM will copy all entries from the vtable of Mammal class to the vtable of Human and adds a new entry for the overloaded version of speak(String).

JVM knows that Human class has overridden two methods one is toString() from Object and second is speck() from Mammal . Now instead of creating new entries for these methods with updated references. JVM will modify the references to the already present methods on the same index where they were present earlier and will keep the same method names.




The invokevirtual causes the JVM to treat the value at method reference #4 , not as an address but as the name of a method to look up in the vtable for the current object.

I hope now it would have become a little bit clear that how the JVM mixes constant pool entries and vtable to conclude which method it is going to call.

You can find the complete code on this Github Repository and please feel free to provide your valuable feedback.

Continue reading