Overloaded Method

Method overloading in Java is a mechanism that allows a class to declare multiple methods sharing the exact same identifier, provided that their method signatures differ. It is an implementation of compile-time polymorphism (static binding), where the Java compiler resolves which specific method implementation to invoke based on the arguments passed at the call site.

In Java, a method signature consists of the method name, the parameter list, and type parameters (generics). To successfully overload a method, the signature must be modified in at least one of the following ways:

1. Arity: Changing the total number of parameters.
2. Type: Changing the data types of the parameters.
3. Order: Changing the sequence of the parameter data types.

public class OverloadMechanics {

    // Base method
    public void execute(int a) { }

    // Valid: Differing arity
    public void execute(int a, int b) { }

    // Valid: Differing parameter data type
    public void execute(double a) { }

    // Valid: Differing sequence of parameter types
    public void execute(int a, double b) { }
    public void execute(double a, int b) { }
}

Invalid Overloading and Type Erasure

The return type, access modifiers, and declared exceptions are part of the method declaration but are not part of the method signature. Attempting to overload a method by changing only these elements results in an ambiguous declaration and triggers a compile-time error.

Furthermore, because Java implements generics via type erasure, generic type parameters are removed during compilation. Overloading methods with generic types that erase to the identical raw type results in a signature collision.

import java.util.List;

public class InvalidOverload {
    
    public int compute(int x) { return x; }

    // COMPILE-TIME ERROR: Return type variation is insufficient
    /*
    public double compute(int x) { return (double) x; }
    */

    public void process(List<String> list) { }

    // COMPILE-TIME ERROR: Type erasure reduces both to process(List)
    /*
    public void process(List<Integer> list) { }
    */
}

The Three Phases of Method Resolution

When an overloaded method is invoked, the Java compiler determines the appropriate method to bind using a strict three-phase resolution process. The compiler stops searching as soon as it finds a match in a given phase.

1. Strict Invocation (Exact Match and Primitive Widening): The compiler searches for an exact type match. If none exists, it applies implicit primitive widening conversions (e.g., byte → short → int → long → float → double) or reference subtyping.
2. Loose Invocation (Autoboxing and Unboxing): If strict invocation yields no match, the compiler attempts to box or unbox the arguments (e.g., converting an int to an Integer, or a Double to a double).
3. Variable Arity Invocation: If loose invocation fails, the compiler attempts to match methods by implicitly packing individual arguments into an array for variable-length arguments (varargs).

public class ResolutionPhases {
    
    public void process(long a) { }    // Phase 1: Primitive Widening
    public void process(Integer a) { } // Phase 2: Autoboxing
    public void process(int... a) { }  // Phase 3: Variable Arity Invocation

    public static void main(String[] args) {
        ResolutionPhases obj = new ResolutionPhases();
        
        int value = 5;
        // Binds to process(long). 
        // Phase 1 (Widening) takes precedence over Phase 2 (Autoboxing).
        obj.process(value); 
    }
}

Reference Types and the Most Specific Type Rule

When resolving overloaded methods involving reference types, the compiler applies the “most specific type” rule. If an argument is compatible with multiple overloaded parameter types, the compiler selects the method declaring the most derived type (the lowest subclass in the inheritance hierarchy).

If the compiler detects multiple equally specific matches on divergent inheritance branches, it throws an ambiguous method call error.

public class ReferenceResolution {
    
    public void identify(Object obj) { }
    public void identify(String str) { }

    public static void main(String[] args) {
        ReferenceResolution ref = new ReferenceResolution();
        
        // The literal 'null' is of the null type, which is implicitly a 
        // subtype of all reference types, making it applicable to both methods.
        // Binds to identify(String) because String is a subclass of Object,
        // making it the most specific applicable type.
        ref.identify(null); 
    }
}

Overloading with Varargs

A method declared with variable-length arguments (varargs) participates in all three phases of method resolution. During Phase 1 (Strict Invocation) and Phase 2 (Loose Invocation), the compiler treats the varargs parameter as a standard fixed-arity array. It is only the variable arity invocation—the act of the compiler implicitly packing individual arguments into an array—that is exclusive to Phase 3.

public class VarargsOverload {
    
    public void log(int a) { }
    public void log(int... a) { }

    public static void main(String[] args) {
        VarargsOverload obj = new VarargsOverload();
        
        // Exact match for int: Binds to log(int) in Phase 1
        obj.log(5);             
        
        // Exact match for int[]: Binds to log(int...) in Phase 1
        // The compiler treats log(int...) as log(int[]) during Strict Invocation.
        obj.log(new int[]{5});  
        
        // Variable arity invocation: Binds to log(int...) in Phase 3
        // The compiler implicitly packs the arguments into an array.
        obj.log(1, 2);          
        
        // Variable arity invocation (empty): Binds to log(int...) in Phase 3
        obj.log();              
    }
}

Master Java with Deep Grasping Methodology!

Learn More