{"title":"Method Overriding","description":"","content":"The last two chapters showed subclasses replacing parent methods to print different messages or compute different totals, without naming what was happening. The mechanism is called method overriding, and the rules around it are stricter than they look. This lesson lays out exactly when a method actually overrides its parent, when it accidentally creates a new method instead, what the compiler enforces, and why `@Override` is the cheapest bug-prevention tool in Java.\n\n---\n\n# What Overriding Is\n\nMethod overriding happens when a subclass defines a method with the same signature as a method it inherits from its parent, and replaces the parent's implementation with its own. The subclass version runs when the method is called on an instance of the subclass, even when the instance is held through a parent-typed variable.\n\nA small product hierarchy to make that concrete. `Product` knows how to describe itself in a generic way. `Book` is a `Product` that wants a richer description.\n\n\n```java\npublic class OverrideBasics {\n public static void main(String[] args) {\n Product generic = new Product(\"Wireless Mouse\", 29.99);\n Product book = new Book(\"Effective Java\", 45.00, \"Joshua Bloch\");\n\n System.out.println(generic.describe());\n System.out.println(book.describe());\n }\n}\n\nclass Product {\n protected String name;\n protected double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \" at $\" + price;\n }\n}\n\nclass Book extends Product {\n private String author;\n\n public Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n\n @Override\n public String describe() {\n return name + \" by \" + author + \" at $\" + price;\n }\n}\n```\n\n\nTwo things matter here. First, `Book.describe()` replaces `Product.describe()` entirely for `Book` instances. Second, the variable `book` is declared as `Product`, but the call resolves to `Book.describe()` because Java looks at the actual object, not the variable's declared type. That last point is the heart of runtime polymorphism, covered at the end of this lesson.\n\n\n```mermaid\nflowchart TD\n Call[book.describe call
book is Product variable
holding a Book object]:::cyan --> Check{What is the
actual object?}:::orange\n Check -->|Book| BookM[Run Book.describe]:::green\n Check -->|Product| ProdM[Run Product.describe]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe declared type of the variable picks which methods are visible to the compiler. The actual object picks which version actually runs. This distinction comes back several times in this lesson.\n\n---\n\n# Overloading vs Overriding\n\nThese two words sound similar and are easy to confuse. They are not related concepts. Overloading happens inside one class. Overriding happens across a parent-child pair.\n\n\n| Aspect | Overloading | Overriding |\n| --- | --- | --- |\n| Where it happens | Same class | Subclass replacing parent's method |\n| Same method name? | Yes | Yes |\n| Same parameter list? | No (must differ) | Yes (must match exactly) |\n| Return type | Can be anything | Same or covariant subtype |\n| Access modifier | Independent | Same or more permissive |\n| Resolved when? | Compile time (static types of args) | Runtime (actual object type) |\n| What it's for | Multiple call shapes for one action | Specialized behavior in a subclass |\n\n\nOverloading is about giving callers different ways to invoke the same operation. Overriding is about a subclass saying \"for this exact operation, do it my way instead.\" Changing the parameter list in a subclass while expecting to override actually overloads the method, which means the parent's version still runs for any inherited call. That's one of the bugs `@Override` exists to catch.\n\n---\n\n# The Five Overriding Rules\n\nFor a subclass method to actually override a parent method, five conditions must all be true. The compiler enforces every one of them.\n\n1. **Same method name.** Capitalization counts. `Describe` and `describe` are different methods.\n2. **Same parameter list.** Same number of parameters, same types in the same order. Parameter names don't matter, but everything else about the types must match exactly. Even autoboxing doesn't count: `(int)` and `(Integer)` are different signatures.\n3. **Return type is the same or covariant.** Covariant means the child's return type is a subtype of the parent's return type. We give covariant returns their own section below.\n4. **Access modifier is the same or more permissive.** A `protected` method in the parent can be overridden as `protected` or `public`, but not `private` or package-private. Visibility cannot be reduced.\n5. **Checked exceptions can be the same, narrower, fewer, or none.** A child override cannot throw new or broader checked exceptions than the parent declares. Unchecked exceptions (subclasses of `RuntimeException`) are unrestricted.\n\nThe decision tree for \"is this an override?\" looks like this.\n\n\n```mermaid\nflowchart TD\n Start[Subclass method M
vs parent method M]:::cyan --> Q1{Same name?}:::orange\n Q1 -->|No| New1[Not an override
just a new method]:::red\n Q1 -->|Yes| Q2{Same parameter
list exactly?}:::orange\n Q2 -->|No| New2[Overload, not override
parent version still inherited]:::red\n Q2 -->|Yes| Q3{Return type same
or covariant subtype?}:::orange\n Q3 -->|No| Err1[Compile error:
incompatible return type]:::red\n Q3 -->|Yes| Q4{Access same or
more permissive?}:::orange\n Q4 -->|No| Err2[Compile error:
cannot reduce visibility]:::red\n Q4 -->|Yes| Q5{Checked exceptions
same, narrower, or fewer?}:::orange\n Q5 -->|No| Err3[Compile error:
incompatible throws clause]:::red\n Q5 -->|Yes| Done[Valid override]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe next few subsections walk through each rule with code that compiles and code that doesn't.\n\n### Rule 1 and 2: Same Name, Same Parameter List\n\nThese two are the obvious ones, but they're also where most accidental \"non-overrides\" happen. The parent method silently keeps running when the parameter list doesn't quite match.\n\n\n```java\npublic class AccidentalOverload {\n public static void main(String[] args) {\n Product p = new DiscountedProduct(\"USB Cable\", 9.99);\n System.out.println(p.describe());\n }\n}\n\nclass Product {\n String name;\n double price;\n\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return \"Product: \" + name + \" at $\" + price;\n }\n}\n\nclass DiscountedProduct extends Product {\n DiscountedProduct(String name, double price) {\n super(name, price);\n }\n\n // Looks like an override, but it isn't.\n // Parameter list differs (added an int), so this is an overload.\n public String describe(int verbosity) {\n return \"Discounted product: \" + name + \" at $\" + price;\n }\n}\n```\n\n\nThe author of `DiscountedProduct` probably intended `p.describe()` to print \"Discounted product...\". It didn't. The new method took an extra `int`, so the compiler treated it as a different method altogether. The original `Product.describe()` is still inherited and still runs. No error, no warning, just wrong behavior.\n\nThe fix is to match the signature exactly, or to add `@Override` so the compiler refuses to compile the mismatch in the first place.\n\n### Rule 3: Return Type Must Be Same or Covariant\n\nIf the parent returns `String`, the child can return `String`. The child can also return a subtype of `String`, but `String` is `final`, so in practice that just means `String`. With non-`final` parent return types, the child has more options. Covariants get their own section because they're useful enough to deserve real coverage.\n\nA widened return type, on the other hand, is not allowed. If the parent returns `Book` and the child tries to return `Product`, the compiler rejects it.\n\n\n```java\nclass Product { /* ... */ }\nclass Book extends Product { /* ... */ }\n\nclass Catalog {\n public Book findFeatured() { return new Book(); }\n}\n\nclass WideningReturnFails extends Catalog {\n @Override\n public Product findFeatured() { return new Product(); } // does NOT compile\n}\n```\n\n\nThe compiler reports something like:\n\n\n```shell\nerror: findFeatured() in WideningReturnFails cannot override findFeatured() in Catalog\n return type Product is not compatible with Book\n```\n\n\nWhy this restriction? Callers of `Catalog.findFeatured()` are entitled to a `Book` based on the parent's contract. If a subclass could return any `Product`, those callers would break. Returning a narrower type is safe, returning a wider one is not.\n\n### Rule 4: Access Cannot Be Narrowed\n\nIf the parent method is `public`, the override must be `public`. Not `protected`, not package-private, not `private`. The principle is that any caller able to legally call the parent method must also be able to call the override, because they might be holding a child instance through a parent-typed variable without knowing it.\n\n\n```java\nclass Product {\n public String describe() {\n return \"A product\";\n }\n}\n\nclass Book extends Product {\n @Override\n protected String describe() { // does NOT compile\n return \"A book\";\n }\n}\n```\n\n\nThe compiler error reads:\n\n\n```shell\nerror: describe() in Book cannot override describe() in Product\n attempting to assign weaker access privileges; was public\n```\n\n\nThe other direction is allowed. Overriding a `protected` parent method with a `public` child method is fine, because that widens access rather than narrowing it.\n\n\n| Parent's access | Child override can be |\n| --- | --- |\n| `public` | `public` only |\n| `protected` | `protected` or `public` |\n| package-private (default) | package-private, `protected`, or `public` |\n| `private` | Not inherited at all, so not overridable. See \"What Cannot Be Overridden\". |\n\n\n### Rule 5: Checked Exceptions Cannot Be Broadened\n\nA child override is allowed to throw the same checked exceptions as the parent, narrower ones (subclasses), fewer of them, or none. It cannot add new checked exceptions or replace an existing one with a broader type.\n\n\n```java\nimport java.io.IOException;\nimport java.io.FileNotFoundException;\n\nclass OrderStore {\n public void save() throws IOException {\n // parent declares IOException\n }\n}\n\nclass FileOrderStore extends OrderStore {\n @Override\n public void save() throws FileNotFoundException {\n // narrower than IOException, allowed\n }\n}\n\nclass CloudOrderStore extends OrderStore {\n @Override\n public void save() {\n // throws nothing, allowed\n }\n}\n\nclass BadOrderStore extends OrderStore {\n @Override\n public void save() throws Exception { // NOT allowed\n // Exception is broader than IOException\n }\n}\n```\n\n\nThe last one fails with:\n\n\n```shell\nerror: save() in BadOrderStore cannot override save() in OrderStore\n overridden method does not throw java.lang.Exception\n```\n\n\nThe reasoning is the same shape as the access rule. Callers of `OrderStore.save()` only catch `IOException`. If a child slipped in a broader `Exception`, those callers would suddenly have unhandled checked exceptions in code that the compiler had previously approved. To keep the parent's contract honest, children can only throw the same or less.\n\nUnchecked exceptions (`RuntimeException` and its subclasses) escape this rule entirely. A child can throw `IllegalArgumentException` from an override even if the parent declared no exceptions. The compiler doesn't enforce `throws` clauses for unchecked exceptions, so it doesn't check them on overrides either.\n\n---\n\n# The `@Override` Annotation\n\n`@Override` is an annotation placed right above a method intended to override a parent. It tells the compiler: \"this method overrides something in a parent class or interface. If it doesn't, please refuse to compile.\" It changes no behavior at runtime. Its entire job is to catch the silent-failure cases just shown.\n\n\n```java\npublic class OverrideAnnotation {\n public static void main(String[] args) {\n Product b = new Book(\"Effective Java\", 45.00, \"Joshua Bloch\");\n System.out.println(b.describe());\n }\n}\n\nclass Product {\n String name;\n double price;\n\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \" at $\" + price;\n }\n}\n\nclass Book extends Product {\n String author;\n\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n\n @Override\n public String describe() {\n return name + \" by \" + author + \" at $\" + price;\n }\n}\n```\n\n\nWithout the `@Override` annotation, this still works. So why bother?\n\nConsider a typo in the method name during a refactor.\n\n\n```java\nclass Book extends Product {\n // ...\n\n @Override\n public String descripe() { // typo: \"descripe\" not \"describe\"\n return name + \" by \" + author + \" at $\" + price;\n }\n}\n```\n\n\nThe compiler error reads:\n\n\n```shell\nerror: method does not override or implement a method from a supertype\n @Override\n ^\n```\n\n\nWithout `@Override`, this typo would compile cleanly. The class would have two methods, the inherited `describe()` from `Product` and a brand-new `descripe()` defined here. Calls to `book.describe()` would silently run the parent's version. A reader scanning the code would see the override and assume it ran. Bugs like this are surprisingly hard to find because nothing crashes, the output is just subtly wrong.\n\n`@Override` catches every shape of accidental non-override: typos in the name, wrong parameter types, wrong number of parameters, wrong order of parameters. Any of those means the method doesn't actually match a parent method, and `@Override` turns that mismatch into a compile error.\n\nThe rule of thumb is simple: put `@Override` on every method intended as an override. There's no downside. It costs nothing at runtime, makes the intent obvious to readers, and traps the entire class of bugs where a \"missed\" override silently falls back to the parent.\n\n---\n\n# Covariant Return Types\n\nRule 3 said the override's return type can be the same as the parent's or a covariant subtype. Covariant return types let a subclass return a more specific type than the parent declared. This is useful in practice, not just an edge case.\n\nThe example: a `Catalog` has a method `featuredItem()` that returns a `Product`. A subclass `BookCatalog` only ever stocks books, so its `featuredItem()` should return a `Book`. Java lets the return type be tightened.\n\n\n```java\npublic class CovariantReturn {\n public static void main(String[] args) {\n Catalog generic = new Catalog();\n BookCatalog books = new BookCatalog();\n\n Product p = generic.featuredItem();\n Book b = books.featuredItem(); // no cast needed\n\n System.out.println(p.describe());\n System.out.println(b.describe() + \" by \" + b.author);\n }\n}\n\nclass Product {\n String name;\n double price;\n\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \" at $\" + price;\n }\n}\n\nclass Book extends Product {\n String author;\n\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\nclass Catalog {\n public Product featuredItem() {\n return new Product(\"Wireless Mouse\", 29.99);\n }\n}\n\nclass BookCatalog extends Catalog {\n @Override\n public Book featuredItem() { // covariant: Book is a subtype of Product\n return new Book(\"Effective Java\", 45.00, \"Joshua Bloch\");\n }\n}\n```\n\n\nThe line doing the real work is `Book b = books.featuredItem();`. Without covariant returns, the override would have to return `Product`, and the caller would have to cast: `Book b = (Book) books.featuredItem();`. Every cast is a place where the type system stops helping, and a place where a future change can introduce a `ClassCastException`. Covariant returns push that knowledge into the type system so the cast disappears.\n\nCovariant returns came in with Java 5. Before that, every override had to return exactly the parent's type. The feature is the reason patterns like `clone()` can return a precise type instead of bare `Object`.\n\nCovariant returns add zero runtime cost. The compiler inserts a small bridge method internally so the parent's signature still works for callers holding a parent reference.\n\nThe only constraint is the direction. The return type can only get narrower, not wider. A child returning `Product` when the parent returns `Book` would fail to compile, as the Rule 3 section showed.\n\n---\n\n# What Cannot Be Overridden\n\nNot every method in a parent class is up for grabs. Four kinds of \"methods\" in the parent are off-limits for overriding, and each one is off-limits for a different reason.\n\n### `final` Methods\n\nA method marked `final` says \"this implementation is the one, and no subclass gets to change it.\" Trying to override it is a compile error.\n\n\n```java\nclass Product {\n public final String sku() {\n return name + \"-SKU\";\n }\n\n String name = \"Wireless Mouse\";\n}\n\nclass Book extends Product {\n @Override\n public String sku() { // does NOT compile\n return \"BOOK-\" + name;\n }\n}\n```\n\n\nThe error reads:\n\n\n```shell\nerror: sku() in Book cannot override sku() in Product\n overridden method is final\n```\n\n\nAuthors mark methods `final` when the method's behavior is part of a guarantee the class wants to preserve, regardless of what subclasses do. Hash-key calculations, identity checks, security gates, anything where a misbehaving override would break invariants. `final` shows up on fields and parameters more often than on methods, but on methods it's a way to lock down behavior that shouldn't shift across the hierarchy.\n\n### `static` Methods\n\n`static` methods belong to the class, not to any instance. They aren't part of an object's behavior, so the runtime polymorphism that powers overriding doesn't apply to them. If a subclass defines a `static` method with the same signature as a `static` method in the parent, what happens isn't overriding. It's a separate feature called **method hiding**, covered in its own section below.\n\n### `private` Methods\n\n`private` methods aren't inherited by the subclass at all. The subclass can't see them, can't call them, can't override them. If the subclass happens to define a method with the same name and signature as a parent's `private` method, it's just a brand-new method that happens to share a name. There's no relationship between the two, and `@Override` on it fails to compile.\n\n\n```java\nclass Product {\n private String secretSauce() {\n return \"internal logic\";\n }\n}\n\nclass Book extends Product {\n // This is NOT an override. It's a new private method.\n private String secretSauce() {\n return \"book-specific logic\";\n }\n\n // The next line would fail to compile because secretSauce is not inherited.\n // @Override\n // private String secretSauce() { return \"book\"; }\n}\n```\n\n\nThe first `secretSauce` in `Book` compiles fine, but it has no connection to the parent's. Calls inside `Product`'s methods that hit `secretSauce()` will still run the parent's version, because the parent doesn't even know the child has a method by that name.\n\n### Constructors\n\nConstructors aren't methods. They have no return type (not even `void`), their name is fixed by the class name, and they don't get inherited. There's no concept of \"overriding a constructor\" because there's nothing to override. A child class writes its own constructors that, by chaining, invoke a parent constructor. That's a different mechanism.\n\nA summary table of what each modifier means for overriding.\n\n\n| Parent method has | Inherited? | Can subclass override? | What happens if subclass declares same signature? |\n| --- | --- | --- | --- |\n| Default behavior (instance method, non-`final`) | Yes | Yes | Overrides |\n| `final` | Yes | No | Compile error |\n| `static` | Yes (as a class member) | No | Hides, doesn't override (see next section) |\n| `private` | No | No | Creates a new, unrelated method |\n| Constructor | N/A | N/A | Subclass writes its own, chained via `super(...)` |\n\n\n---\n\n# Method Hiding: When `static` Methods Look Overridden but Aren't\n\nThis is the most confusing corner of the lesson, so it gets its own section.\n\nWhen a subclass defines a `static` method with the same signature as a `static` method in the parent, it doesn't override the parent's method. It **hides** it. The difference is which version gets called: hiding picks based on the declared (compile-time) type of the variable, while overriding picks based on the actual (runtime) object.\n\nThe example shows the difference clearly.\n\n\n```java\npublic class StaticHiding {\n public static void main(String[] args) {\n Product p = new Book();\n\n // Instance method: overriding. Picks by actual object.\n System.out.println(p.describe());\n\n // Static method: hiding. Picks by declared type of p.\n System.out.println(p.category());\n }\n}\n\nclass Product {\n public String describe() {\n return \"A generic product\";\n }\n\n public static String category() {\n return \"Products\";\n }\n}\n\nclass Book extends Product {\n @Override\n public String describe() {\n return \"A book\";\n }\n\n // Hides the parent's static method. No @Override allowed here.\n public static String category() {\n return \"Books\";\n }\n}\n```\n\n\nThe variable `p` is declared `Product` but holds a `Book`. The instance method call `p.describe()` runs `Book.describe()` because Java looks at the actual object. The static method call `p.category()` runs `Product.category()` because Java looks at the declared type of `p`. Same variable, two different rules, because `describe` is an instance method and `category` is a static method.\n\nPutting `@Override` on `Book.category()` causes the compiler to reject it:\n\n\n```shell\nerror: method does not override or implement a method from a supertype\n @Override\n ^\n```\n\n\nThat's because `@Override` only applies to overriding, and `static` methods don't override. They hide.\n\nThe takeaway: don't write `static` methods expecting subclass polymorphism. For behavior that varies by subclass, use instance methods. `static` methods are for class-level utilities where the type of the variable, not the type of the object, is what matters.\n\n---\n\n# Runtime Resolution: A Preview of Polymorphism\n\nThe phrase \"Java looks at the actual object\" has appeared three times now. This is the defining feature of overriding, and it has a name: **runtime polymorphism** (also called dynamic dispatch or late binding).\n\nThe compiler doesn't decide which override runs. It can't, because it only knows the declared type of the variable, and that type might just be a parent. The decision is made when the program runs and Java looks up the actual class of the object on the heap.\n\n\n```java\npublic class RuntimeDispatch {\n public static void main(String[] args) {\n Product[] catalog = {\n new Product(\"Wireless Mouse\", 29.99),\n new Book(\"Effective Java\", 45.00, \"Joshua Bloch\"),\n new Product(\"USB Cable\", 9.99)\n };\n\n for (Product p : catalog) {\n System.out.println(p.describe());\n }\n }\n}\n\nclass Product {\n String name;\n double price;\n\n Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \" at $\" + price;\n }\n}\n\nclass Book extends Product {\n String author;\n\n Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n\n @Override\n public String describe() {\n return name + \" by \" + author + \" at $\" + price;\n }\n}\n```\n\n\nThe variable `p` in the loop is typed `Product`. The compiler only knows the declared type, but it generates code that, at runtime, asks each actual object which version of `describe` to run. The `Book` object answers with `Book.describe`. The other two answer with `Product.describe`. One loop, three call sites, two different methods, all because of runtime polymorphism.\n\nRuntime dispatch adds a small indirection (one pointer hop through the object's method table) compared to a static call. In normal code this is invisible. In hot code paths, the JIT compiler often inlines virtual calls when it can prove the type is fixed, so the cost effectively disappears.\n\nThe takeaway is that overriding is what makes runtime polymorphism work, and runtime polymorphism is what makes overriding worth having.","pageType":"java"}

Method Overriding

Get Premium