Overloading and overriding share a name prefix and both involve methods with the same name — and that surface similarity is exactly why beginners confuse them. They solve completely different problems, work at different stages of program execution, and belong to different types of polymorphism.

Overloading says: this class has multiple methods named calculate, each accepting different inputs. The compiler picks the right one before the program even runs. Overriding says: this subclass has its own version of makePayment that replaces the parent's version. The JVM picks the right one at runtime, after it knows what kind of object is actually being used.

Understanding the difference is not just interview preparation — it shapes how you design every class hierarchy you write.

What Is Method Overloading?

Method overloading is when a class defines two or more methods with the same name but different parameter lists. The methods can differ in the number of parameters, the types of parameters, or the order of parameter types. The return type alone cannot distinguish overloaded methods.

Overloading is resolved entirely at compile time. The compiler examines the argument types you pass and selects the matching method signature before generating bytecode. This is why overloading is called compile-time polymorphism or static polymorphism.

Java

// File: TaxCalculator.java

public class TaxCalculator {

    // Calculates GST for a basic amount
    public double calculateTax(double amount) {
        return amount * 0.18;
    }

    // Calculates tax with a custom rate
    public double calculateTax(double amount, double rate) {
        return amount * rate;
    }

    // Calculates tax for an integer quantity times unit price
    public double calculateTax(int quantity, double unitPrice) {
        return quantity * unitPrice * 0.18;
    }

    // Returns a formatted tax summary string
    public String calculateTax(double amount, String category) {
        double rate = category.equals("essential") ? 0.05 : 0.18;
        return category + " tax on Rs." + amount + " = Rs." + (amount * rate);
    }
}

Java

// File: OverloadingDemo.java

public class OverloadingDemo {

    public static void main(String[] args) {

        TaxCalculator calc = new TaxCalculator();

        // Compiler picks calculateTax(double) based on one double argument
        System.out.println("GST: Rs." + calc.calculateTax(10000.0));

        // Compiler picks calculateTax(double, double) — two doubles
        System.out.println("Custom rate: Rs." + calc.calculateTax(10000.0, 0.12));

        // Compiler picks calculateTax(int, double) — int then double
        System.out.println("Qty tax: Rs." + calc.calculateTax(5, 2000.0));

        // Compiler picks calculateTax(double, String) — double then String
        System.out.println(calc.calculateTax(5000.0, "essential"));
    }
}

Output:
GST: Rs.1800.0
Custom rate: Rs.1200.0
Qty tax: Rs.1800.0
essential tax on Rs.5000.0 = Rs.250.0

The method name calculateTax appears four times. The compiler resolves which version to call based on the number and types of arguments at each call site. No inheritance involved — overloading works within a single class.

What Is Method Overriding?

Method overriding is when a subclass provides its own implementation of a method that already exists in the parent class. The method name, parameter list, and return type must match the parent's declaration. The @Override annotation makes the intent explicit and lets the compiler catch mistakes.

Overriding is resolved at runtime. The JVM examines the actual type of the object at the moment of the call and dispatches to the most specific implementation in the class hierarchy. This is why overriding is called runtime polymorphism or dynamic dispatch.

Java

// File: PaymentProcessor.java

public class PaymentProcessor {

    // Parent defines the contract — every payment type must implement this
    public String processPayment(double amount) {
        return "Processing Rs." + amount + " via default channel.";
    }

    public String getProcessorName() {
        return "Default Processor";
    }
}

Java

// File: UpiPaymentProcessor.java

public class UpiPaymentProcessor extends PaymentProcessor {

    private final String upiId;

    public UpiPaymentProcessor(String upiId) {
        this.upiId = upiId;
    }

    // Overrides parent — JVM calls THIS version when object is UpiPaymentProcessor
    @Override
    public String processPayment(double amount) {
        return "UPI transfer of Rs." + amount + " from " + upiId + " — initiated.";
    }

    @Override
    public String getProcessorName() {
        return "UPI Processor";
    }
}

Java

// File: CardPaymentProcessor.java

public class CardPaymentProcessor extends PaymentProcessor {

    private final String maskedCard;

    public CardPaymentProcessor(String maskedCard) {
        this.maskedCard = maskedCard;
    }

    @Override
    public String processPayment(double amount) {
        return "Card charge of Rs." + amount + " on " + maskedCard + " — authorised.";
    }

    @Override
    public String getProcessorName() {
        return "Card Processor";
    }
}

Java

// File: OverridingDemo.java

import java.util.List;

public class OverridingDemo {

    public static void main(String[] args) {

        // Reference type is PaymentProcessor — actual types vary
        List<PaymentProcessor> processors = List.of(
            new PaymentProcessor(),
            new UpiPaymentProcessor("rahul@upi"),
            new CardPaymentProcessor("**** **** **** 4521")
        );

        for (PaymentProcessor processor : processors) {
            // JVM decides at runtime which processPayment() to call
            System.out.println("[" + processor.getProcessorName() + "] "
                + processor.processPayment(2499.0));
        }
    }
}

Output:
[Default Processor] Processing Rs.2499.0 via default channel.
[UPI Processor] UPI transfer of Rs.2499.0 from rahul@upi — initiated.
[Card Processor] Card charge of Rs.2499.0 on **** **** **** 4521 — authorised.

All three objects are referenced as PaymentProcessor. The for loop calls processPayment the same way on each. The JVM checks the actual object type at runtime and routes to the correct override. This is runtime polymorphism in action — the calling code does not change, but the behaviour does.

Overloading vs Overriding — Complete Comparison

Aspect	Method Overloading	Method Overriding
Definition	Same method name, different parameter list in the same class	Same method name and signature in a subclass replacing the parent's version
Polymorphism type	Compile-time (static) polymorphism	Runtime (dynamic) polymorphism
Resolved at	Compile time — by the compiler	Runtime — by the JVM
Class relationship	Works within a single class (also works across parent-child)	Requires inheritance — parent and child classes
Parameter list	Must differ — type, count, or order	Must be identical
Return type	Can differ (does not alone distinguish overloads)	Must be same or a subtype (covariant return)
Access modifier	Can be anything	Cannot reduce visibility from parent
`@Override` annotation	Not applicable	Strongly recommended — enforced by most teams
`static` methods	Can be overloaded	Cannot be overridden — only hidden
`private` methods	Can be overloaded	Cannot be overridden — not inherited
`final` methods	Can be overloaded	Cannot be overridden
Exception handling	Can throw any exceptions	Cannot add new checked exceptions not declared in parent
When to use	Multiple ways to call the same logic with different inputs	Specialised behaviour in a subclass for an inherited method
Example	`print(int)`, `print(String)`, `print(double)`	`Animal.sound()` overridden by `Dog.sound()`

How Compile-Time vs Runtime Resolution Works

The distinction between when each is resolved is what makes them fundamentally different — not just the rules about signatures.

When the compiler processes an overloaded call, it looks at the static type of the variable and the argument types in the call. It picks the best-matching method signature and records that choice in the bytecode. The program cannot change its mind later.

When the JVM processes an overriding call, it looks at the actual object sitting in memory at that moment. The reference type is ignored for dispatch purposes. Whatever concrete type the object actually is, that type's implementation runs.

Overloading — resolved by compiler:

Source code: calc.calculateTax(5, 2000.0)
                                |    |
                              int  double
                                |
                      Compiler matches to:
                      calculateTax(int, double)
                                |
                      Bytecode records this choice.
                      Cannot change at runtime.


Overriding — resolved by JVM at runtime:

Source code: processor.processPayment(2499.0)
                  |
             Reference type: PaymentProcessor
                  |
             Actual object: UpiPaymentProcessor
                  |
             JVM looks up actual type's method table
                  |
             Calls: UpiPaymentProcessor.processPayment()

This is why you can hold a PaymentProcessor reference and still get UPI-specific behaviour — the reference type controls what the compiler allows you to call, but the actual object type controls which implementation runs.

Overloading vs Overriding — Rules Summary Table

Rule	Overloading	Overriding
Same method name	Required	Required
Same parameter list	Prohibited (at least one must differ)	Required (must match exactly)
Same return type	Not required	Required (or covariant subtype)
Inheritance needed	No	Yes
Works on static methods	Yes	No — static methods are hidden, not overridden
Works on private methods	Yes	No — private methods are not inherited
Works on final methods	Yes	No — final prevents overriding
Checked exception rules	No restrictions	Cannot declare new checked exceptions
Annotation	None required	`@Override` (strongly recommended)

Real-World Example — Notification Service

The Business Problem

A notification service at a company like Swiggy or Meesho sends alerts through multiple channels: SMS, email, and push notifications. Every channel uses the same sendNotification concept, but each has its own delivery mechanism. Additionally, within the SMS channel, the same send operation needs to handle different inputs — just a message, a message with a scheduled time, or a message with a priority flag. Overriding handles the channel variation; overloading handles the input variation within each channel.

Java

// File: Notification.java

public class Notification {

    protected final String recipient;
    protected final String message;

    public Notification(String recipient, String message) {
        this.recipient = recipient;
        this.message   = message;
    }
}

Java

// File: NotificationSender.java

public class NotificationSender {

    // Overloaded — three ways to call send within this class
    public void send(Notification notification) {
        System.out.println("[SENDER] Dispatching to: " + notification.recipient);
    }

    public void send(Notification notification, long scheduledEpoch) {
        System.out.println("[SENDER] Scheduled for epoch " + scheduledEpoch
                + " to: " + notification.recipient);
    }

    public void send(Notification notification, int priorityLevel) {
        System.out.println("[SENDER] Priority " + priorityLevel
                + " dispatch to: " + notification.recipient);
    }

    // Overridden by subclasses — each channel has its own delivery logic
    public String getChannelName() {
        return "Generic";
    }

    public boolean deliver(Notification notification) {
        System.out.println("[" + getChannelName() + "] Delivering: "
                + notification.message + " → " + notification.recipient);
        return true;
    }
}

Java

// File: SmsNotificationSender.java

public class SmsNotificationSender extends NotificationSender {

    private final String smsGateway;

    public SmsNotificationSender(String smsGateway) {
        this.smsGateway = smsGateway;
    }

    @Override
    public String getChannelName() {
        return "SMS";
    }

    @Override
    public boolean deliver(Notification notification) {
        System.out.println("[SMS via " + smsGateway + "] Sending '"
                + notification.message + "' to " + notification.recipient);
        return true;
    }
}

Java

// File: PushNotificationSender.java

public class PushNotificationSender extends NotificationSender {

    private final String appId;

    public PushNotificationSender(String appId) {
        this.appId = appId;
    }

    @Override
    public String getChannelName() {
        return "Push";
    }

    @Override
    public boolean deliver(Notification notification) {
        System.out.println("[Push App:" + appId + "] Sending '"
                + notification.message + "' to device " + notification.recipient);
        return true;
    }
}

Java

// File: NotificationServiceDemo.java

import java.util.List;

public class NotificationServiceDemo {

    public static void main(String[] args) {

        Notification orderAlert = new Notification("9876543210", "Your order is out for delivery!");

        NotificationSender smsSender  = new SmsNotificationSender("Twilio-IN");
        NotificationSender pushSender = new PushNotificationSender("com.meesho.app");

        // Overloading in action — same sender, different call signatures
        smsSender.send(orderAlert);
        smsSender.send(orderAlert, 2);                 // priority overload
        smsSender.send(orderAlert, 1735000000L);       // scheduled overload

        System.out.println();

        // Overriding in action — same reference type, different runtime behaviour
        List<NotificationSender> senders = List.of(smsSender, pushSender);
        for (NotificationSender sender : senders) {
            sender.deliver(orderAlert);
        }
    }
}

Output:
[SENDER] Dispatching to: 9876543210
[SENDER] Priority 2 dispatch to: 9876543210
[SENDER] Scheduled for epoch 1735000000 to: 9876543210

[SMS via Twilio-IN] Sending 'Your order is out for delivery!' to 9876543210
[Push App:com.meesho.app] Sending 'Your order is out for delivery!' to device 9876543210

The send calls on smsSender demonstrate overloading — three calls to send with different arguments, resolved by the compiler. The deliver calls in the loop demonstrate overriding — same reference type, different runtime objects, different output. Both mechanisms work together in the same example without interfering.

Best Practices

Use @Override on every overriding method without exception. A method that is meant to override but has a typo in the name — procesPayment instead of processPayment — silently becomes a new unrelated method without @Override. The annotation makes the compiler catch this mistake immediately.

Keep overloaded methods consistent in their core purpose. Overloading send(message) and send(message, priority) is sensible — the methods do the same thing with different levels of configuration. Overloading send(String message) and send(String filePath) is a code smell — two overloads with the same signature but completely different semantics confuse callers and lead to bugs.

Prefer composition and overriding for varying behaviour, overloading for varying inputs. When you find yourself writing if-else chains inside a method to handle different runtime object types, that is a sign that overriding should be doing the job. When you want to give callers flexibility in what they pass, overloading is the right tool.

Never override static methods and call them polymorphically. Static methods are resolved by reference type at compile time, not by object type at runtime. Placing @Override on a static method in a subclass creates method hiding — the parent version does not disappear, and the dispatch is not polymorphic. This is a common source of subtle bugs.

Common Mistakes

Mistake 1 — Trying to Overload by Return Type Only

Java

public class Calculator {

    public int compute(int value) {
        return value * 2;
    }

    // Compile error — return type alone does not distinguish overloads
    public double compute(int value) {
        return value * 2.0;
    }
}

Compile error: compute(int) is already defined in Calculator

The compiler selects overloads based on argument types, not return type. If the parameter list is identical, the methods are considered duplicates regardless of what they return.

Mistake 2 — Thinking a Subclass Overloads the Parent's Method

Java

public class Base {
    public void display(String message) {
        System.out.println("Base: " + message);
    }
}

public class Child extends Base {

    // This is NOT overloading — it is a new method in Child
    // display(String) from Base is still inherited unchanged
    public void display(int code) {
        System.out.println("Child code: " + code);
    }
}

Child now has two display methods: the inherited display(String) from Base and its own display(int). This is technically an overload across the inheritance hierarchy, but Base.display(String) is not affected. A beginner expecting this to change the parent method's behaviour will be surprised.

Mistake 3 — Reducing Access Modifier in an Override

Java

public class Service {
    public String getStatus() {
        return "Running";
    }
}

public class MockService extends Service {

    // Compile error — cannot reduce visibility from public to protected
    @Override
    protected String getStatus() {
        return "Mock";
    }
}

Compile error: getStatus() in MockService cannot override getStatus() in Service;
attempting to assign weaker access privileges; was public

An overriding method can widen access (from protected to public) but never narrow it. The parent declared public — every caller holding a Service reference expects to call getStatus() publicly, and the override cannot break that expectation.

Mistake 4 — Assuming Static Method Override Is Polymorphic

Java

public class Parent {
    public static String type() { return "Parent"; }
    public        String name() { return "Parent"; }
}

public class Child extends Parent {
    public static String type() { return "Child"; }  // hiding, not overriding
    @Override
    public        String name() { return "Child"; }  // true override
}

public class StaticMistakeDemo {
    public static void main(String[] args) {
        Parent obj = new Child();
        System.out.println(obj.type()); // resolved by reference type: Parent
        System.out.println(obj.name()); // resolved by object type: Child
    }
}

Output:
Parent
Child

type() is static — the compiler resolves it using the reference type (Parent), so "Parent" prints even though the object is a Child. name() is an instance method — the JVM resolves it using the actual object type (Child), so "Child" prints. Static methods are hidden, not overridden, and hiding is never polymorphic.

Interview Questions

Q1. What is the difference between method overloading and method overriding in Java?

Overloading defines multiple methods with the same name but different parameter lists within the same class. The compiler resolves which version to call at compile time — it is static polymorphism. Overriding defines a method in a subclass with the same name and parameter list as a parent method, replacing the parent's implementation. The JVM resolves which version to call at runtime based on the actual object type — it is dynamic polymorphism. They differ in when resolution happens, whether inheritance is needed, and what must match in the signature.

Q2. Can you override a static method in Java?

No. Static methods belong to the class, not to instances, so they cannot participate in runtime polymorphism. When a subclass declares a static method with the same signature as a parent's static method, it is called method hiding — the parent's version still exists and is called when accessed through a parent-type reference. Hiding is resolved at compile time by reference type, so it is never polymorphic. Putting @Override on a static method in a subclass causes a compile error in Java.

Q3. What happens if an overriding method throws a new checked exception not declared in the parent?

It causes a compile error. An overriding method can throw the same checked exceptions declared in the parent, a subset of them, or unchecked exceptions — but it cannot add new checked exceptions that the parent did not declare. This rule protects callers who hold a parent-type reference: they handle only the exceptions the parent declares, so the override cannot surprise them with undeclared ones.

Q4. Can you overload the main method in Java?

Yes. The JVM looks for the specific signature public static void main(String[] args) as the program entry point. You can define additional main methods with different parameter lists — main(int[] args), main(String arg) — and they compile without error. The JVM will not call them automatically at startup, but your own code can call them like any other method.

Q5. What is covariant return type in method overriding?

Covariant return type means an overriding method can return a more specific (subtype) type than the parent method. If the parent returns Animal, the override can return Dog — since Dog is a subtype of Animal. This was introduced in Java 5 and is most commonly seen in factory methods and builder hierarchies where the subclass's factory method returns the specific subclass type, avoiding unnecessary casting for the caller.

Q6. How does the compiler choose between overloaded methods when arguments could match multiple signatures?

The compiler applies a ranking: it first tries exact type match, then widening conversion (int can widen to long, float, double), then autoboxing, then varargs as a last resort. If two signatures match with equal priority and neither is more specific, the compiler reports an ambiguous method call error. This ordering explains why print(int) is preferred over print(long) when you pass an int, and why print(Integer) (autoboxed) is preferred over print(int...) (varargs).

FAQs

Can overloading happen across parent and child classes?

Yes. If a parent class defines display(String) and a child class defines display(int), the child class has both versions available — one inherited, one its own. This is a valid overload that works across the inheritance hierarchy. It is different from overriding because the parameter lists differ and the parent's method is not replaced.

Is method overloading possible with just a different return type?

No. The compiler selects overloaded methods based on argument types and count, not the return type. Two methods with the same name and parameter list but different return types cause a compile error — the compiler considers them duplicates regardless of what they return.

What does @Override do exactly — is it mandatory?

@Override is an annotation that tells the compiler to verify this method genuinely overrides something in a superclass or implements something from an interface. It is not required for overriding to work, but it is treated as mandatory in every serious Java codebase. Without it, a typo in the method name silently creates a new unrelated method instead of an override — a bug that is extremely hard to spot at runtime.

Can a constructor be overloaded? Can it be overridden?

Constructors can be overloaded — having multiple constructors in the same class with different parameter lists is one of the most common patterns in Java. Constructors cannot be overridden — they are not inherited, and overriding requires inheritance. Subclasses call parent constructors via super() but never override them.

What is the difference between method hiding and method overriding?

Method overriding applies to instance methods and is resolved polymorphically at runtime by the JVM based on the actual object type. Method hiding applies to static methods — when a subclass declares a static method with the same signature as a parent's static method, the parent version is hidden but not replaced. Hidden static methods are resolved at compile time by reference type and are never polymorphic. The practical consequence: an object of the child type held in a parent reference will call the parent's static method — not the child's.

Summary

Overloading and overriding are both about methods sharing a name, but the similarity ends there. Overloading gives callers flexibility — multiple signatures for the same concept, resolved before the program runs. Overriding gives subclasses identity — their own behaviour for an inherited contract, resolved when the program is actually executing.

In production code, you use overloading to handle varying input shapes without forcing callers to remember different method names. You use overriding to implement polymorphic behaviour — the core mechanism that makes List, PaymentProcessor, and every other abstraction work without caring about what sits underneath. Getting either wrong produces subtle bugs that compile cleanly and break unpredictably at runtime.

Both appear in almost every Java interview. Interviewers asking about overloading want to see that you understand compile-time resolution and signature rules. Interviewers asking about overriding want to see that you understand the JVM's runtime dispatch, the @Override annotation, and what happens with static methods. The comparison table in this article covers every dimension they are likely to probe.

What to Read Next

Topic	Link
How polymorphism uses method overriding for runtime dispatch in class hierarchies	Java Polymorphism →
How inheritance provides the class hierarchy that overriding builds on	Java Inheritance →
How abstract methods force subclasses to provide an override implementation	Java Abstract Classes →
How interfaces define contracts that implementing classes must override	Java Interfaces →
How constructors can be overloaded to provide flexible object creation	Java Constructors →

←

PreviousMethod Overriding

NextPolymorphism

→