Java Method Overloading: Same Name, Different Parameters

One Name, Several Versions

On the previous page you saw how a method's parameters define what it accepts. Method overloading takes that further: you can give several methods the same name as long as their parameter lists differ. The compiler treats them as distinct methods and picks the right one based on the arguments you pass.

This is why System.out.println happily prints an int, a String, a boolean, or a double - there isn't one println, there are many overloads sharing the name. You write the call you mean and the compiler matches it to the version that fits.

public class Main {
    static int square(int n) {
        return n * n;
    }

    static double square(double n) {
        return n * n;
    }

    public static void main(String[] args) {
        System.out.println(square(5));      // calls the int version  -> 25
        System.out.println(square(2.5));    // calls the double version -> 6.25
    }
}

Both methods are named square, but one takes an int and the other a double. The literal 5 is an int, so the first overload runs; 2.5 is a double, so the second runs.

What Counts as a Different Overload

Overloads must differ in their parameter list - that means at least one of:

• a different number of parameters,
• different parameter types, or
• a different order of types.

public class Main {
    static String join(String a, String b) {
        return a + b;
    }

    static String join(String a, String b, String c) {   // different count
        return a + b + c;
    }

    static String join(String a, int times) {             // different types
        return a.repeat(times);
    }

    public static void main(String[] args) {
        System.out.println(join("a", "b"));
        System.out.println(join("a", "b", "c"));
        System.out.println(join("hi", 3));
    }
}

Each call has a parameter list that matches exactly one of the three join methods, so there is no confusion.

The Return Type Does Not Count

A common beginner trap: trying to overload on return type alone. The return type is not part of the signature the compiler uses, so this fails to compile:

// Does NOT compile - same name, same parameters, only the return type differs
static int   value() { return 1; }
static double value() { return 1.0; }   // error: value() is already defined

The compiler can't tell these apart, because at a call site like value() nothing in the arguments hints at which one you want. You may give overloads different return types, but only when their parameter lists already differ.

How Java Picks an Overload

When more than one overload could accept your arguments, Java chooses the most specific one and prefers an exact type match over a widening conversion. Watch what happens with an int argument:

public class Main {
    static void show(int n)    { System.out.println("int: " + n); }
    static void show(long n)   { System.out.println("long: " + n); }
    static void show(double n) { System.out.println("double: " + n); }

    public static void main(String[] args) {
        show(7);     // exact match -> int
        show(7L);    // exact match -> long
        show(7.0);   // exact match -> double
    }
}

show(7) matches int exactly even though long and double could also hold a 7 after widening. Only if the exact overload were removed would the compiler widen int to long, then to double. This resolution is decided entirely at compile time, based on the declared types of your arguments.

Watch Out for Ambiguous Calls

If no single overload is clearly the best match, the compiler refuses to guess and reports an error. This happens most often with null, which fits any reference type:

static void handle(String s) { }
static void handle(StringBuilder b) { }

handle(null);   // error: reference to handle is ambiguous

Both overloads accept null, and neither is more specific, so the call won't compile. Fix it by making the type explicit with a cast - handle((String) null) - or by redesigning so the overloads don't collide. The same care applies when mixing autoboxing and widening; keep overload sets simple enough that every call has one obvious winner.

Overloading Constructors

Overloading isn't limited to ordinary methods - constructors use it constantly to offer several ways to build an object. A no-argument constructor can hand off to a fuller one with this(...):

public class Main {
    static class Point {
        int x, y;

        Point() {
            this(0, 0);          // delegate to the two-arg constructor
        }

        Point(int x, int y) {
            this.x = x;
            this.y = y;
        }

        public String toString() {
            return "(" + x + ", " + y + ")";
        }
    }

    public static void main(String[] args) {
        System.out.println(new Point());      // (0, 0)
        System.out.println(new Point(3, 4));  // (3, 4)
    }
}

The two constructors share the name Point but differ in parameter count, exactly like overloaded methods. Delegating with this(...) keeps the initialization logic in one place.

Overloading vs Overriding

These two sound alike but are unrelated:

• Overloading - same name, different parameter lists, in the same class. The compiler picks the version at compile time. It's about offering variants of an operation.
• Overriding - a subclass redefines an inherited method with the same name and the same parameters. Java picks the version at runtime based on the object's real type. It's about replacing behavior (you'll meet it under inheritance and polymorphism).

If the parameter lists are identical, you're overriding (or causing a duplicate-method error in the same class); if they differ, you're overloading.

Next: Varargs

Overloading lets you write join(a, b) and join(a, b, c) as separate methods - but what if you want to accept any number of arguments without declaring an overload for each count? Java's varargs syntax lets a single method take a variable-length argument list, and that's the next page.