Method overloading rules in Java

Upasana | May 26, 2019 | 3 min read | 370 views

Overloaded methods let you reuse the same method name in a class, but with different arguments. That makes are API look slightly better from naming perspective.

There are certain rules for method overloading in Java, which we must abide by:

Overloaded method must have different number or different type of arguments.
Overloaded methods can change their return types.
Overloaded methods can change their access modifiers.
Overloaded methods can declare new or broader checked exceptions.
A method can be overloaded in the same class or subclass. That means a method is considered as overloaded if subtype inherits one version of the method and then declares another overloaded version in its own type definition.

Code samples

In the following example, we create two overloaded methods that takes same type but different number of arguments.

Different number of arguments

public class Calculator {

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

    public int sum(int a, int b, int c) {
        return a + b + c;
    }
}

In the next example we will create two overloaded sum methods that takes different types of arguments. First sum method takes two arguments of type int, the second overloaded method takes arguments of type double.

Different type of arguments

public class Calculator {

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

    public int sum(double a, double b) {
        return a + b;
    }
}

In the below code snippet, we see a method overloading example, where class Bar inherits doStuff(int x) from Foo and then add an overloaded version doStuff(String x) in its own type definition.

Method overloading in subclass

public class Foo {
    public void doStuff(int x) {
        //Foo implementation
    }
}

public class Bar extends Foo {

    public void doStuff(String x) {
        //Bar's overloaded implementation
    }

}

Type widening

One given type is implicitly promoted to another one when there’s no matching between the types of the arguments passed to the overloaded method and a specific method implementation.

The following images illustrates the order of the primitive types when widened:

Primitive Type Widening

The below code example will explain this:

What will be the output of this program

class Scratch {
    static String x = "";
    public static void main(String... doYourBest) {
        executeAction(1);
        executeAction(1.0);
        executeAction(Double.valueOf("5"));
        executeAction(1L);

        System.out.println(x);
    }
    static void executeAction(short var)   {x += "d"; }
    static void executeAction(float var)   {x += "e"; }
    static void executeAction(double var)  {x += "f"; }
}

Program output

effe

Explanation

When we pass the number 1 directly to the executeAction method, the JVM automatically treats it as an int. but since no matching method exists, the type is promoted to float automatically (as shown in diagram) that’s why we see e.
When we pass 1.0, JVM treats it as double, so f is printed.
When we pass Double.valueOf("5"), then auto-boxing makes compiler choose f.
When we pass 1L, then we specifically ask JVM to treat this argument as long, as per primitive type widening next available matching method is that of float, this e is printed.