Method overriding is when a child class provides its own implementation of a method that already exists in the parent class. The method name, parameter list, and return type must match — but the body is replaced with the child's version. At runtime, the JVM looks at the actual type of the object and calls the most specific implementation it finds.

This is the engine of runtime polymorphism. Without overriding, every object of every subtype would behave identically to the parent — the point of having a hierarchy in the first place disappears. Overriding is what gives each subclass its own identity.

What Is Method Overriding?

Method overriding happens when a subclass declares a method with the same name, same parameter list, and a compatible return type as a method in its parent class. The child's version replaces the parent's version for any object of the child type, regardless of what reference type is used to call it.

Three things must be true for a method to override rather than simply exist alongside the parent's:

›The method name must be identical
›The parameter list must be identical — same types, same count, same order
›The return type must be the same or a subtype (covariant return)

If any of these differ, the method is not an override — it is an overload or a new method entirely.

Basic Method Overriding Example

Java

// File: Animal.java

public class Animal {

    private final String name;

    public Animal(String name) {
        this.name = name;
    }

    public String getName() { return name; }

    // Parent version — used when no override exists
    public String makeSound() {
        return name + " makes a generic animal sound.";
    }

    public String describe() {
        return "Animal: " + name + " | Sound: " + makeSound();
    }
}

Java

// File: Dog.java

public class Dog extends Animal {

    private final String breed;

    public Dog(String name, String breed) {
        super(name);
        this.breed = breed;
    }

    public String getBreed() { return breed; }

    // Overrides Animal.makeSound() — replaces the parent's body
    @Override
    public String makeSound() {
        return getName() + " barks: Woof! Woof!";
    }
}

Java

// File: Cat.java

public class Cat extends Animal {

    private final boolean isIndoor;

    public Cat(String name, boolean isIndoor) {
        super(name);
        this.isIndoor = isIndoor;
    }

    @Override
    public String makeSound() {
        return getName() + " meows: Meow~";
    }
}

Java

// File: OverridingBasicDemo.java

import java.util.List;

public class OverridingBasicDemo {

    public static void main(String[] args) {

        List<Animal> animals = List.of(
                new Animal("Generic Animal"),
                new Dog("Bruno", "Labrador"),
                new Cat("Whiskers", true)
        );

        for (Animal animal : animals) {
            // JVM dispatches to the correct override at runtime
            System.out.println(animal.describe());
        }
    }
}

Output:
Animal: Generic Animal | Sound: Generic Animal makes a generic animal sound.
Animal: Bruno | Sound: Bruno barks: Woof! Woof!
Animal: Whiskers | Sound: Whiskers meows: Meow~

The loop calls animal.describe() — which is a concrete method in Animal. Inside describe(), it calls this.makeSound(). At runtime, this refers to the actual object — Dog or Cat — so the JVM dispatches to the correct makeSound() override. The parent's describe() method is reused by all subclasses; only makeSound() varies.

The @Override Annotation

@Override is not required for overriding to work — but it is required in professional Java code. It tells the compiler to verify that this method genuinely overrides something in a parent class or interface. If it does not — because of a typo in the name or a wrong parameter type — the compiler reports an error rather than silently creating a new unrelated method.

Java

public class WrongOverrideDemo extends Animal {

    public WrongOverrideDemo() { super("Test"); }

    // Without @Override — this creates a NEW method, not an override
    // makeSound is misspelled — no error reported, override silently fails
    public String makeSounds() {  // wrong name — s at the end
        return "This never gets called polymorphically";
    }

    // With @Override — compiler catches the mistake immediately
    // @Override
    // public String makeSounds() { ... }
    // Compile error: method does not override or implement a method from a supertype
}

Every production Java codebase enforces @Override on every overriding method. It is the fastest way to catch the most common overriding mistake — a method that was supposed to override but does not because of a typo or wrong signature.

Method Overriding Rules

Rule	Description	Example
Same method name	Must match exactly — case-sensitive	`makeSound()` overrides `makeSound()`
Same parameter list	Same types, count, and order	`(String s)` cannot override `(int i)`
Compatible return type	Same type or a subtype (covariant)	`Dog` can override returning `Animal` with returning `Dog`
Same or wider access	Cannot reduce visibility	`public` cannot be overridden as `protected`
No new checked exceptions	Can throw fewer or unchecked; not new checked	Cannot add `throws IOException` if parent does not declare it
Cannot override `final`	`final` methods are locked	Compile error if attempted
Cannot override `static`	Static methods are hidden, not overridden	`static` method uses method hiding, not polymorphism
Cannot override `private`	Private methods are invisible to child	Child declares a new method, not an override
Must use `@Override`	Not enforced by compiler — enforced by teams	Best practice: always use it

Covariant Return Types

Java allows an overriding method to return a subtype of the parent's return type. This is called a covariant return type and makes overrides more specific without violating the contract.

Java

// File: VehicleFactory.java

public class VehicleFactory {

    // Parent returns the general type
    public Vehicle createVehicle() {
        return new Vehicle("DEFAULT", "Standard");
    }
}

Java

// File: ElectricVehicleFactory.java

public class ElectricVehicleFactory extends VehicleFactory {

    // Override returns a more specific subtype — covariant return
    @Override
    public ElectricVehicle createVehicle() {
        return new ElectricVehicle("EV-001", "Electric", 75);
    }
}

Java

// File: Vehicle.java

public class Vehicle {

    private final String vehicleId;
    private final String type;

    public Vehicle(String vehicleId, String type) {
        this.vehicleId = vehicleId;
        this.type      = type;
    }

    public String getVehicleId() { return vehicleId; }
    public String getType()      { return type; }

    public String getSummary() {
        return vehicleId + " | Type: " + type;
    }
}

Java

// File: ElectricVehicle.java

public class ElectricVehicle extends Vehicle {

    private final int batteryKwh;

    public ElectricVehicle(String vehicleId, String type, int batteryKwh) {
        super(vehicleId, type);
        this.batteryKwh = batteryKwh;
    }

    public int getBatteryKwh() { return batteryKwh; }

    @Override
    public String getSummary() {
        return super.getSummary() + " | Battery: " + batteryKwh + " kWh";
    }
}

Java

// File: CovariantReturnDemo.java

public class CovariantReturnDemo {

    public static void main(String[] args) {

        VehicleFactory         standardFactory  = new VehicleFactory();
        ElectricVehicleFactory electricFactory  = new ElectricVehicleFactory();

        Vehicle standard = standardFactory.createVehicle();
        // ElectricVehicle is returned — no cast needed from ElectricVehicleFactory
        ElectricVehicle electric = electricFactory.createVehicle();

        System.out.println(standard.getSummary());
        System.out.println(electric.getSummary());
        System.out.println("Battery: " + electric.getBatteryKwh() + " kWh");
    }
}

Output:
DEFAULT | Type: Standard
EV-001 | Type: Electric | Battery: 75 kWh
Battery: 75 kWh

ElectricVehicleFactory.createVehicle() returns ElectricVehicle — a subtype of Vehicle. This is valid because ElectricVehicle is-a Vehicle. The caller of ElectricVehicleFactory gets back the specific type directly, with no casting needed. This pattern is common in factory methods and builder hierarchies.

super.method() in Overriding — Extending vs Replacing

An override can either completely replace the parent behaviour or extend it using super.method(). The choice depends on whether the parent's logic is still needed.

Java

// File: BaseLogger.java

public class BaseLogger {

    protected String prefix;

    public BaseLogger(String prefix) {
        this.prefix = prefix;
    }

    public void log(String message) {
        System.out.println("[" + prefix + "] " + message);
    }
}

Java

// File: TimestampLogger.java

import java.time.LocalTime;
import java.time.format.DateTimeFormatter;

public class TimestampLogger extends BaseLogger {

    public TimestampLogger(String prefix) {
        super(prefix);
    }

    // Extends parent behaviour — adds timestamp without duplicating base logic
    @Override
    public void log(String message) {
        String time = LocalTime.now().format(DateTimeFormatter.ofPattern("HH:mm:ss"));
        super.log("[" + time + "] " + message); // reuses parent's format
    }
}

Java

// File: SuperInOverrideDemo.java

public class SuperInOverrideDemo {

    public static void main(String[] args) {

        BaseLogger     base      = new BaseLogger("APP");
        TimestampLogger timed    = new TimestampLogger("APP");

        base.log("Server started");
        timed.log("Server started");
    }
}

Output:
[APP] Server started
[APP] [10:30:45] Server started

TimestampLogger.log() calls super.log() to reuse the parent's formatting and adds the timestamp on top. Without super.log(), it would need to duplicate the bracket-and-prefix formatting — and any future change to the parent format would not propagate to the child.

Method Overriding vs Method Hiding

Static methods cannot be overridden — they are hidden. This is a critical difference that directly affects polymorphic behaviour.

Aspect	Method Overriding	Method Hiding
Applies to	Instance methods	Static methods
Resolved at	Runtime — actual object type	Compile time — reference type
Polymorphic	Yes — JVM dispatches to correct override	No — reference type always wins
`@Override`	Works correctly	Can be written but misleading
Keyword	None extra	`static` on both parent and child
Behaviour through parent ref	Child's version runs	Parent's version runs

Java

// File: OverridingVsHidingDemo.java

public class OverridingVsHidingDemo {

    static class Parent {
        public static String staticMethod()   { return "Parent static"; }
        public        String instanceMethod() { return "Parent instance"; }
    }

    static class Child extends Parent {
        // Hiding — NOT overriding (static)
        public static String staticMethod()   { return "Child static"; }

        // Overriding — true polymorphism (instance)
        @Override
        public        String instanceMethod() { return "Child instance"; }
    }

    public static void main(String[] args) {

        Parent ref = new Child(); // reference type: Parent, actual type: Child

        // Static — resolved at compile time by reference type
        System.out.println("Static via Parent ref : " + Parent.staticMethod());
        System.out.println("Static via Child ref  : " + Child.staticMethod());

        // Instance — resolved at runtime by actual object type
        System.out.println("Instance via Parent ref: " + ref.instanceMethod());
    }
}

Output:
Static via Parent ref : Parent static
Static via Child ref  : Child static
Instance via Parent ref: Child instance

The static method is resolved by the reference type — Parent.staticMethod() always returns "Parent static" regardless of the actual object. The instance method is resolved by the actual object type — ref.instanceMethod() returns "Child instance" even though ref is declared as Parent. This is the polymorphism difference.

Real-World Example — Payroll Calculation System

The Business Problem

You are building the payroll engine for a staffing company — similar to what Infosys or Wipro uses for its HR systems. Full-time employees get basic salary plus allowances minus deductions. Contract employees get a daily rate times days worked. Both are Employee objects. The payroll runner processes all employees through one loop without knowing the concrete type — overriding handles the rest.

Implementation

Java

// File: PayrollConfig.java

public final class PayrollConfig {

    public static final double DA_RATE  = 0.10;
    public static final double HRA_RATE = 0.15;
    public static final double PF_RATE  = 0.12;

    private PayrollConfig() {}
}

Java

// File: Employee.java

public abstract class Employee {

    private final String employeeId;
    private final String fullName;
    private final String department;

    protected Employee(String employeeId, String fullName, String department) {
        this.employeeId = employeeId;
        this.fullName   = fullName;
        this.department = department;
    }

    public String getEmployeeId() { return employeeId; }
    public String getFullName()   { return fullName; }
    public String getDepartment() { return department; }

    // Abstract — each subclass calculates pay differently
    public abstract double calculateMonthlyPay();

    // Concrete — shared payslip format; calls overridden calculateMonthlyPay()
    public String generatePaySlip() {
        return String.format("%-10s | %-22s | %-18s | Pay: Rs.%,.2f",
                employeeId, fullName, department, calculateMonthlyPay());
    }
}

Java

// File: FullTimeEmployee.java

public class FullTimeEmployee extends Employee {

    private final double basicSalary;

    public FullTimeEmployee(String employeeId, String fullName,
                             String department, double basicSalary) {
        super(employeeId, fullName, department);
        this.basicSalary = basicSalary;
    }

    @Override
    public double calculateMonthlyPay() {
        double da  = basicSalary * PayrollConfig.DA_RATE;
        double hra = basicSalary * PayrollConfig.HRA_RATE;
        double pf  = basicSalary * PayrollConfig.PF_RATE;
        return basicSalary + da + hra - pf;
    }
}

Java

// File: ContractEmployee.java

public class ContractEmployee extends Employee {

    private final double dailyRate;
    private final int    daysWorked;

    public ContractEmployee(String employeeId, String fullName,
                             String department, double dailyRate, int daysWorked) {
        super(employeeId, fullName, department);
        this.dailyRate  = dailyRate;
        this.daysWorked = daysWorked;
    }

    @Override
    public double calculateMonthlyPay() {
        return dailyRate * daysWorked; // no allowances or deductions for contract
    }
}

Java

// File: PayrollDemo.java

import java.util.List;

public class PayrollDemo {

    public static void main(String[] args) {

        List<Employee> payroll = List.of(
                new FullTimeEmployee("FT-001", "Ananya Krishnan",   "Backend Eng", 85000.0),
                new FullTimeEmployee("FT-002", "Rohan Desai",       "DevOps",      72000.0),
                new ContractEmployee("CT-001", "Priya Mehta",       "QA",    3500.0, 22),
                new ContractEmployee("CT-002", "Karan Singh",       "Design",4000.0, 18)
        );

        System.out.println("=== Monthly Payroll ===\n");
        double totalPayroll = 0;
        for (Employee emp : payroll) {
            System.out.println(emp.generatePaySlip());
            totalPayroll += emp.calculateMonthlyPay();
        }
        System.out.printf("%nTotal payroll: Rs.%,.2f%n", totalPayroll);
    }
}

Output:
=== Monthly Payroll ===

FT-001     | Ananya Krishnan        | Backend Eng       | Pay: Rs.96,050.00
FT-002     | Rohan Desai            | DevOps            | Pay: Rs.81,360.00
CT-001     | Priya Mehta            | QA                | Pay: Rs.77,000.00
CT-002     | Karan Singh            | Design            | Pay: Rs.72,000.00

Total payroll: Rs.3,26,410.00

The payroll loop calls emp.generatePaySlip() on every Employee. generatePaySlip() calls calculateMonthlyPay() internally — which dispatches to FullTimeEmployee.calculateMonthlyPay() or ContractEmployee.calculateMonthlyPay() at runtime. No instanceof check, no if-else by type. Just one loop, one method call, correct result for each type.

Best Practices

Always annotate overrides with @Override

Every professional Java team enforces this. Without @Override, a typo or signature mismatch silently creates a new method instead of overriding. The annotation costs nothing and catches mistakes before they reach runtime.

Use super.method() when extending, not when replacing

If the child's override adds to the parent's behaviour, call super.method() and append the extra logic. If the override completely replaces the parent's behaviour, do not call super.method() — omitting it is the signal that the parent's code is no longer relevant.

Keep overriding methods focused on their own responsibility

An overriding method should do what the parent declared — not more. When an override starts adding unrelated side effects — sending emails, updating databases, modifying shared state — it violates the principle of least surprise. Callers of the parent type do not expect these side effects.

Never call overridable methods from constructors

When a constructor calls an overridable method, Java dispatches to the child's override even before the child constructor's body has run. The child's fields are at their default values. This produces NullPointerException or incorrect results that are extremely difficult to diagnose.

Common Mistakes

Mistake 1 — Wrong Parameter Type Causes Overload Instead of Override

Java

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

public class SmsNotifier extends Notifier {

    // Intended to override — but parameter type is Object, not String
    // This is an OVERLOAD, not an override
    @Override  // Compile error — correctly caught by @Override
    public void send(Object message) {
        System.out.println("SMS: " + message);
    }
}

Without @Override, this compiles silently. send(String) on an SmsNotifier reference would call Notifier.send(String) — never reaching the child's method. @Override catches this immediately.

Mistake 2 — Reducing Access Modifier in Override

Java

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

public class MockService extends Service {

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

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

An overriding method cannot be less visible than the parent. The parent declared public — the override must also be public. Any caller who holds a Service reference expects to call getStatus() publicly — the override cannot break that expectation.

Mistake 3 — Declaring a New Checked Exception in an Override

Java

import java.io.IOException;

public class DataReader {
    public String readData() { return "data"; }
}

public class FileDataReader extends DataReader {

    // Compile error — cannot add new checked exception not in parent
    @Override
    public String readData() throws IOException { // error
        return "file data";
    }
}

Compile error: readData() in FileDataReader cannot override readData() in DataReader;
overridden method does not throw IOException

A caller holding a DataReader reference does not know to handle IOException — it was not declared in the parent. Adding it would break all callers. The fix is to declare it in the parent, use RuntimeException (unchecked), or wrap the checked exception.

Interview Questions

Q1. What is method overriding in Java?

Method overriding is when a child class declares a method with the same name, same parameter list, and a compatible return type as a method in its parent class. At runtime, the JVM calls the child's version when the actual object type is the child — regardless of the reference type used. It is the mechanism behind runtime polymorphism and dynamic dispatch. @Override annotation makes the intent explicit and lets the compiler verify the override is correct.

Q2. What is the difference between method overriding and method hiding in Java?

Method overriding applies to instance methods — the JVM resolves which implementation to call at runtime based on the actual object type. This is polymorphic. Method hiding applies to static methods — when a child declares a static method with the same signature as a parent's static method, the parent's version is hidden but not replaced. The version called is determined by the reference type at compile time, not the actual object type at runtime. Static methods are not polymorphic.

Q3. What are the rules for method overriding in Java?

The overriding method must have the same name and parameter list as the parent. The return type must be the same or a subtype (covariant return). The access modifier must be the same or wider — cannot reduce visibility. No new checked exceptions may be declared that are not in the parent's throws clause. The method cannot be private, static, or final in the parent — all three prevent overriding. Using @Override is not required by the compiler but is mandatory in professional code.

Q4. What is a covariant return type in method overriding?

A covariant return type allows an overriding method to return a subtype of the parent method's return type. If the parent method returns Animal, the child can override it to return Dog — since Dog is-a Animal. This makes factory methods and builder hierarchies more precise because callers of the child class get back the specific type without casting.

Q5. Why should overridable methods not be called from constructors?

When a constructor calls an instance method that is overridden in a child class, Java dispatches to the child's override — even before the child's constructor body has run. The child's fields are still at their default values: null, 0, or false. The overriding method then operates on uninitialised state, producing incorrect results that are extremely difficult to debug. Only private or final methods — which cannot be overridden — are safe to call from constructors.

Q6. Can you override a private method in Java?

No. Private methods are not visible to subclasses — they are not inherited. A child class can declare a method with the same name and signature as a parent's private method, but it is a completely new, unrelated method — not an override. Calling the method through a parent-type reference will always invoke the parent's private version; the child's version is never called polymorphically.

FAQs

What is method overriding in Java?

Method overriding is when a subclass provides its own implementation of a method declared in the parent class. The signature must match exactly. At runtime, the JVM calls the child's version based on the actual object type — enabling runtime polymorphism.

Is @Override mandatory in Java?

The compiler does not require it. But every professional Java team treats it as mandatory because it tells the compiler to verify the override is correct. Without it, a typo in the method name or a wrong parameter type silently creates a new method instead of overriding, causing the polymorphism to silently fail.

Can you override a static method in Java?

No. Static methods cannot be overridden — they can only be hidden. A child can declare a static method with the same signature, but it is not polymorphic. The version called depends on the reference type at compile time, not the actual object type at runtime.

What is the difference between overriding and overloading?

Overriding redefines an inherited method in a child class — same name, same parameters, resolved at runtime. Overloading defines multiple methods with the same name but different parameters in the same or a child class — resolved at compile time. Overriding is runtime polymorphism; overloading is compile-time polymorphism.

Can you override a final method in Java?

No. A method declared final in the parent cannot be overridden in any subclass. Attempting to do so is a compile-time error. final on a method guarantees that the parent's implementation is the one that always runs, regardless of the actual object type.

What happens to the parent method when a child overrides it?

The parent method still exists in the parent class. It is accessible through super.method() from within the child's overriding method. Objects of the parent type still call the parent's version. Only objects of the child type (or further subclasses) use the child's override. The parent method is not deleted — it is replaced in the method dispatch chain for the child type only.

Summary

Method overriding is the direct implementation of runtime polymorphism — one method name, one call, different behaviour depending on the actual object type at runtime. The JVM resolves overrides through dynamic dispatch at runtime, not compile-time. The rules — same name, same parameters, compatible return type, same or wider access, no new checked exceptions — are what the compiler checks when @Override is present.

The most practically important rule is @Override on every override. It turns a silent runtime bug (wrong method name, wrong parameter type) into an immediate compile error. The second most important is understanding the difference between overriding (instance methods, polymorphic) and hiding (static methods, not polymorphic) — this distinction is tested in virtually every Java interview.

What to Read Next

Topic	Link
How method overloading differs from overriding — compile-time vs runtime	Overloading vs Overriding →
How polymorphism uses method overriding for runtime dispatch	Java Polymorphism →
How inheritance provides the class hierarchy that overriding builds on	Java Inheritance →
How abstract methods force every subclass to provide an override	Java Abstract Classes →
How the super keyword calls the parent version of an overridden method	Java super Keyword →

←

Previoussuper Keyword

NextOverloading vs Overriding

→