Method Overloading vs Overriding in Java

Overloading is compile time polymorphism; overriding is run time polymorphism. In overloading, several methods share a name in the same class but take different parameter lists, and the compiler picks one based on the static types of the arguments at the call site. Nothing about it depends on the object involved. In overriding, a subclass declares a method with the same signature as one in its superclass, and the JVM picks the implementation based on the actual type of the object at run time.

That difference explains why the two look so similar in code but behave differently. In the example below, the same call site resolves the overload at compile time from the argument types, while the overridden method is chosen at run time from the object's real class even though the variable is declared as the base type.

public class Main {
    public static void main(String[] args) {
        Printer printer = new LaserPrinter();

        // Overloading: resolved by the compiler from the argument types.
        System.out.println(printer.print("hello"));
        System.out.println(printer.print(7));

        // Overriding: resolved at run time from the object's real type.
        System.out.println(printer.describe());
    }
}

class Printer {
    String print(String text) { return "overload(String): " + text; }

    String print(int number) { return "overload(int): " + number; }

    String describe() { return "base describe"; }
}

class LaserPrinter extends Printer {
    @Override
    String describe() { return "overridden describe"; }
}

Overriding has strict rules that make it safe: the name and parameter list must match exactly, the return type must be identical or covariant, the access modifier cannot be tightened, checked exceptions cannot be broadened, and the method must not be final or private, and the class must not be final. The @Override annotation is not required, but putting it on every overriding method turns those rules into compile-time checks instead of silent conventions, which is why it is close to mandatory in modern code.

No. A static method is a member of the class, not of the instances, so there is no object for the runtime to dispatch on. When a subclass declares a static method with the same signature as one in its superclass, the language says the subclass method hides the superclass method rather than overriding it.

The consequence is that the choice is made at compile time from the static type of the reference, exactly like overloading. If the variable is typed as the base class, the base class's static method runs, even though the object is an instance of the subclass. If the variable is typed as the subclass, the subclass's static method runs.

public class Main {
    public static void main(String[] args) {
        Base base = new Child();

        // Hiding: chosen by the compiler from the static type of the reference.
        base.staticMethod();

        // Overriding: chosen at run time from the object's real type.
        base.instanceMethod();
    }
}

class Base {
    static void staticMethod() {
        System.out.println("Base.staticMethod");
    }

    void instanceMethod() {
        System.out.println("Base.instanceMethod");
    }
}

class Child extends Base {
    static void staticMethod() {
        System.out.println("Child.staticMethod");
    }

    @Override
    void instanceMethod() {
        System.out.println("Child.instanceMethod");
    }
}

The output shows the asymmetry perfectly: the static call prints Base.staticMethod because the reference is declared as Base, while the instance call prints Child.instanceMethod because the object really is a Child. You can add @Override to a method that hides a static one and the compiler accepts it, which is a small inconsistency worth knowing about. The same rule applies to private methods, which are not inherited at all and so can never be overridden, and to final methods, whose overrides are a compile error.

Because of type erasure. A generic method's type parameters are not part of its runtime signature, so void process(List<String>) and void process(List<Integer>) both erase to void process(List). The compiler sees two methods with the identical name and identical erased parameter types, which is a duplicate declaration, and rejects the class.

This is why the Java language has no true support for overloads that differ only by type argument, unlike C++ templates. It is a deliberate trade-off: erasure keeps the binary format simple and lets a generic class work with code written before generics existed, at the cost of this limitation.

Three workarounds cover most real cases. The first is to use different method names, which is the honest fix when the two operations really are different — processStrings and processIntegers reads better than an overload the reader must disambiguate. The second is to make the method generic: a single <T> void process(List<T> items) handles every element type, and the compiler infers T from the argument. The third is to add a distinguishing parameter, such as a marker or an extra argument, so the erased signatures no longer collide.

One related edge case worth mentioning: you cannot overload on the number of type parameters either, since <T> void m(T a) and <T, U> void m(T a, U b) are distinguished by arity of the value parameters, which does work — but <T> void m(T a) and <T, U> void m(T a) erase to the same thing and clash.