{"title":"Default Methods","description":"","content":"Interfaces started life as a pure contract: a list of method signatures that implementers had to fill in. That worked until Java 8 had to add new methods to interfaces like `Collection` and `Iterable` without breaking the millions of classes already implementing them. The fix was a small but powerful change to the language: an interface can now ship a method with a body, marked with the `default` keyword, that every implementing class inherits automatically. This lesson covers why default methods exist, how they behave, the diamond problem they introduce, and how the compiler forces it to be resolved.\n\n---\n\n# Why Default Methods Exist\n\nConsider the situation Java's library team faced in 2014. The `java.util.Collection` interface had been around since 1998. Every `List`, `Set`, and `Queue` implementation across the ecosystem implemented it. Java 8 wanted to add `stream()` to `Collection` so any collection could produce a stream of its elements. The natural way would be to add a new abstract method to the interface.\n\nThat one line would have been catastrophic. Every class implementing `Collection` anywhere in the world would suddenly fail to compile because they didn't implement `stream()`. Library upgrades that should have been routine would have required code changes in every implementer.\n\nA default method solves this. The interface ships with a working implementation. Existing classes inherit it without changing a line. Classes that want a smarter version can override it.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class WhyDefaultsExist {\n public static void main(String[] args) {\n List wishlist = new ArrayList<>();\n wishlist.add(\"Wireless Mouse\");\n wishlist.add(\"Mechanical Keyboard\");\n\n // forEach is a default method on Iterable, added in Java 8.\n // ArrayList didn't change. It got forEach automatically.\n wishlist.forEach(item -> System.out.println(\"Want: \" + item));\n }\n}\n```\n\n\n`ArrayList` doesn't define `forEach`. It inherits the default from `Iterable`. The library team got to add behavior to an old interface and didn't break a single existing implementer. This is the design problem default methods were built to solve: backward-compatible interface evolution.\n\n---\n\n# Syntax and Basic Behavior\n\nA default method looks like a regular method declaration except that it's inside an interface and it starts with the `default` keyword. The body is just a method body. No magic.\n\n\n```java\npublic class DefaultSyntaxDemo {\n public static void main(String[] args) {\n Discountable book = new Book(\"Effective Java\", 45.00);\n System.out.println(\"Original: $\" + book.basePrice());\n System.out.println(\"Final: $\" + book.finalPrice());\n }\n}\n\ninterface Discountable {\n double basePrice();\n\n // Default method: gives every implementer a working finalPrice automatically.\n default double finalPrice() {\n return basePrice();\n }\n}\n\nclass Book implements Discountable {\n private String name;\n private double price;\n\n public Book(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n @Override\n public double basePrice() {\n return price;\n }\n}\n```\n\n\n`Book` only implements `basePrice()`. It picks up `finalPrice()` from the interface. The default body uses `basePrice()`, which dispatches polymorphically to `Book.basePrice()`, so the default can build on top of the abstract methods the implementer is required to provide.\n\nA few rules sit underneath that example:\n\n\n| Rule | What it means |\n| --- | --- |\n| `default` only inside an interface | A `default` method in a class is a compile error. |\n| Always `public` | Interface members are implicitly public. Marking a default method `private` is a different feature, covered in a later chapter. |\n| Has a body | The whole point. No body, no default. |\n| Can call other interface methods | Including abstract ones, which dispatch to the implementer. |\n| Counts as inherited, not implemented | Implementing classes don't have to write it, but they can. |\n\n\n---\n\n# Overriding a Default Method\n\nDefault methods are inherited, but they aren't sealed. An implementing class can override any default method to give a more specific implementation. The override looks exactly like overriding a normal method.\n\n\n```java\npublic class OverrideDefault {\n public static void main(String[] args) {\n Discountable regular = new Book(\"Effective Java\", 45.00);\n Discountable clearance = new ClearanceBook(\"Old Java Book\", 30.00);\n\n System.out.println(\"Regular final: $\" + regular.finalPrice());\n System.out.println(\"Clearance final: $\" + clearance.finalPrice());\n }\n}\n\ninterface Discountable {\n double basePrice();\n\n default double finalPrice() {\n return basePrice();\n }\n}\n\nclass Book implements Discountable {\n protected String name;\n protected double price;\n\n public Book(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n @Override\n public double basePrice() {\n return price;\n }\n}\n\nclass ClearanceBook extends Book {\n public ClearanceBook(String name, double price) {\n super(name, price);\n }\n\n // Override the default to apply a 40% clearance discount.\n @Override\n public double finalPrice() {\n return basePrice() * 0.6;\n }\n}\n```\n\n\n`Book` inherits the default `finalPrice()` from `Discountable` and never overrides it. `ClearanceBook` overrides it to subtract 40%. When you call `finalPrice()` on a `Discountable` reference, the JVM does the same dynamic dispatch it does for any instance method: it looks at the actual object's class to pick the right body.\n\nThat property matters for performance and the design model. A default method dispatches like a virtual method. It is not a static call, it is not a copy paste into every implementer, and it is not pre resolved at compile time. The class that implements the interface either has its own override of the method (use that) or it does not (walk up to the interface's default).\n\nDefault method calls go through `invokeinterface`, which costs the same as any other virtual call: a method table lookup plus a jump. The JIT inlines monomorphic call sites like it does for class methods, so in normal code the cost is invisible.\n\n---\n\n# Default Methods Can Call Other Interface Methods\n\nA useful pattern with default methods is layering. Declare a few small abstract methods that implementers must provide, then build richer default methods on top of them. The implementers only have to write the minimum, and they get the rest automatically.\n\n\n```java\npublic class LayeredDefaults {\n public static void main(String[] args) {\n Discountable book = new Book(\"Effective Java\", 45.00);\n Discountable bundle = new Bundle(\"Java Starter Kit\", 120.00, 0.25);\n\n System.out.println(book.priceSummary());\n System.out.println(bundle.priceSummary());\n }\n}\n\ninterface Discountable {\n double basePrice();\n\n default double discountRate() {\n return 0.0;\n }\n\n default double finalPrice() {\n return basePrice() * (1 - discountRate());\n }\n\n default String priceSummary() {\n return \"Base: $\" + basePrice()\n + \", Discount: \" + (discountRate() * 100) + \"%\"\n + \", Final: $\" + finalPrice();\n }\n}\n\nclass Book implements Discountable {\n private String name;\n private double price;\n\n public Book(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n @Override\n public double basePrice() {\n return price;\n }\n}\n\nclass Bundle implements Discountable {\n private String name;\n private double price;\n private double rate;\n\n public Bundle(String name, double price, double rate) {\n this.name = name;\n this.price = price;\n this.rate = rate;\n }\n\n @Override\n public double basePrice() {\n return price;\n }\n\n @Override\n public double discountRate() {\n return rate;\n }\n}\n```\n\n\n`Book` only implements `basePrice()`. It inherits the default `discountRate()` (which returns 0), the default `finalPrice()`, and the default `priceSummary()`. `Bundle` adds an override for `discountRate()`, and everything else recomputes correctly because `finalPrice()` and `priceSummary()` call back into the interface methods, which dispatch to whichever implementation the actual object provides.\n\nThis is the same template-method pattern that abstract classes use, but it works without forcing implementers to extend a particular parent. A class can extend whatever it needs and still pick up the layered behavior by implementing the interface.\n\n\n```mermaid\nflowchart LR\n Caller[Caller: discountable.priceSummary]:::cyan --> Default[Interface default
priceSummary calls
basePrice + discountRate + finalPrice]:::orange\n Default --> Base{basePrice
on object?}:::orange\n Default --> Rate{discountRate
on object?}:::orange\n Default --> Final{finalPrice
on object?}:::orange\n Base -->|Yes| BaseImpl[Run object's basePrice]:::green\n Rate -->|No override| RateDef[Run default
discountRate returns 0]:::teal\n Rate -->|Override| RateImpl[Run object's discountRate]:::green\n Final -->|No override| FinalDef[Run default finalPrice]:::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 diagram makes the dispatch chain visible. The default `priceSummary()` doesn't hard-code anything. Every call inside it goes back through dynamic dispatch, so each implementer can override whichever piece it cares about without rewriting the whole thing.\n\n---\n\n# The Diamond Problem\n\nSingle inheritance avoids one of the oldest headaches in object-oriented design: what happens when a class inherits the same method from two unrelated parents. Java's classes can only extend one parent, so the question used to never come up. A class can implement many interfaces, though, and once interfaces ship method bodies, the question is back. If two interfaces both define a `default` method with the same signature, which one does the implementing class get?\n\nConsider this setup. An e-commerce app has two interfaces. `Notifiable` says \"I can send a notification about an order\" and provides a default body. `Loggable` says \"I can log activity\" and also provides a default `notify(String)` body (the names overlap on purpose to expose the conflict). A class that implements both interfaces inherits two competing defaults with the same signature.\n\n\n```java\n// THIS DOES NOT COMPILE.\npublic class DiamondConflict {\n public static void main(String[] args) {\n OrderService svc = new OrderService();\n svc.notifyCustomer(\"Order shipped\");\n }\n}\n\ninterface Notifiable {\n default void notifyCustomer(String message) {\n System.out.println(\"[Notification] \" + message);\n }\n}\n\ninterface Loggable {\n default void notifyCustomer(String message) {\n System.out.println(\"[Log] \" + message);\n }\n}\n\nclass OrderService implements Notifiable, Loggable {\n // Inherits two conflicting defaults. Compiler refuses.\n}\n```\n\n\nThe compiler's actual error reads:\n\n\n```shell\nerror: class OrderService inherits unrelated defaults for notifyCustomer(String) from types Notifiable and Loggable\nclass OrderService implements Notifiable, Loggable {\n^\n```\n\n\nThis is Java's version of the diamond problem. Two unrelated paths bring the same default method into one class, and the language refuses to pick one without an explicit choice. The implementing class has to resolve the conflict explicitly.\n\n\n```mermaid\nflowchart TD\n N[Notifiable
default notifyCustomer]:::cyan\n L[Loggable
default notifyCustomer]:::orange\n O[OrderService
implements both]:::red\n\n N --> O\n L --> O\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diagram is the classic diamond shape (minus the top point, since the two interfaces don't share an ancestor here). `OrderService` sits at the bottom and faces two defaults flowing into it from above. Java forces it to pick.\n\n---\n\n# Resolving the Conflict\n\nThe fix is to override the conflicting method in the implementing class. The override can hold any body, including calling one or both of the interface defaults explicitly with the `Interface.super.method(...)` syntax.\n\n\n```java\npublic class DiamondResolved {\n public static void main(String[] args) {\n OrderService svc = new OrderService();\n svc.notifyCustomer(\"Order shipped\");\n }\n}\n\ninterface Notifiable {\n default void notifyCustomer(String message) {\n System.out.println(\"[Notification] \" + message);\n }\n}\n\ninterface Loggable {\n default void notifyCustomer(String message) {\n System.out.println(\"[Log] \" + message);\n }\n}\n\nclass OrderService implements Notifiable, Loggable {\n @Override\n public void notifyCustomer(String message) {\n // Call both parents in a chosen order.\n Notifiable.super.notifyCustomer(message);\n Loggable.super.notifyCustomer(message);\n }\n}\n```\n\n\nThe override solves the ambiguity in two ways at once. It signals the disambiguation to the compiler, and it documents exactly which behavior the class wants. `Notifiable.super.notifyCustomer(message)` is a special syntax that calls the default body from `Notifiable`. Without the `Notifiable.super` prefix, the compiler wouldn't know which interface's body was meant.\n\nThe override doesn't need to call either parent. It can do something completely different:\n\n\n```java\nclass OrderService implements Notifiable, Loggable {\n @Override\n public void notifyCustomer(String message) {\n System.out.println(\"[OrderService] \" + message + \" (sent to all channels)\");\n }\n}\n```\n\n\nThe implementing class is back in control. Once an override is in place, the inherited defaults are no longer in play unless the override explicitly calls them.\n\n---\n\n# Resolution Rule 1: Class Wins Over Interface\n\nIf a class inherits a method from both a superclass and an interface, the superclass version wins. The interface default is shadowed entirely. This rule keeps the language consistent with the pre-Java-8 world, where every method came from a class.\n\n\n```java\npublic class ClassWinsDemo {\n public static void main(String[] args) {\n DiscountedOrder order = new DiscountedOrder();\n System.out.println(order.tag());\n }\n}\n\ninterface Tagged {\n default String tag() {\n return \"tag from interface\";\n }\n}\n\nclass Order {\n public String tag() {\n return \"tag from class\";\n }\n}\n\nclass DiscountedOrder extends Order implements Tagged {\n // Inherits tag() from both Order (class) and Tagged (interface).\n // Class wins. No override needed.\n}\n```\n\n\n`DiscountedOrder` doesn't write a single line about `tag()`, and the call resolves to `Order.tag()` because the superclass beats any interface default. This is sometimes called the \"class wins\" rule, and the reasoning is straightforward: an existing class hierarchy that worked before Java 8 still works the same way after Java 8, even with interface defaults around it.\n\nTo use the interface's version instead, override `tag()` in `DiscountedOrder` and explicitly call `Tagged.super.tag()`.\n\n---\n\n# Resolution Rule 2: More Specific Interface Wins\n\nWhen two interfaces are involved and one extends the other, the more specific (sub-interface) one wins. The compiler doesn't see this as a conflict, because there's a clear precedence: the sub-interface refined the parent's contract.\n\n\n```java\npublic class SubInterfaceWins {\n public static void main(String[] args) {\n VipNotifier notifier = new VipNotifier();\n notifier.notifyCustomer(\"Order shipped\");\n }\n}\n\ninterface Notifiable {\n default void notifyCustomer(String message) {\n System.out.println(\"[Standard] \" + message);\n }\n}\n\ninterface VipNotifiable extends Notifiable {\n @Override\n default void notifyCustomer(String message) {\n System.out.println(\"[VIP] \" + message);\n }\n}\n\nclass VipNotifier implements Notifiable, VipNotifiable {\n // Inherits notifyCustomer from both.\n // VipNotifiable extends Notifiable, so VipNotifiable wins. No conflict.\n}\n```\n\n\n`VipNotifier` lists both interfaces in `implements`, but `VipNotifiable extends Notifiable`, so the compiler treats `VipNotifiable` as the more specific source. It picks `VipNotifiable.notifyCustomer` and never asks the class to disambiguate.\n\n\n```mermaid\nflowchart TD\n N[Notifiable
default notifyCustomer]:::cyan\n V[VipNotifiable extends Notifiable
overrides notifyCustomer]:::orange\n C[VipNotifier
implements both]:::green\n\n N --> V\n V --> C\n N -.->|shadowed| C\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```\n\n\nThe dashed edge in the diagram shows that `Notifiable`'s default reaches `VipNotifier` only through `VipNotifiable`'s override. The original default never wins.\n\nThis rule is purely compile-time. It only affects which body the compiler binds to the call site through interface resolution. The runtime dispatch cost is identical.\n\n---\n\n# Resolution Rule 3: Otherwise, You Must Override\n\nWhen neither rule 1 nor rule 2 applies (no superclass version, no sub-interface relationship between the conflicting interfaces), the class is stuck with two equally valid candidates. The compiler refuses to pick. The class must override the method, which is exactly what the `Notifiable` + `Loggable` example earlier did.\n\nThe three rules apply in order. The compiler walks through them top to bottom:\n\n\n| Rule | What it checks | Outcome if matched |\n| --- | --- | --- |\n| 1. Class wins | Is there a superclass method with the same signature? | Use the superclass method. Interface defaults are ignored. |\n| 2. More specific interface wins | Among interface candidates, is one a sub-interface of another? | Use the most specific interface's default. |\n| 3. Otherwise | Two or more unrelated interface defaults remain. | Compile error. The class must override. |\n\n\n---\n\n# The `Interface.super.method()` Syntax\n\nAn override sometimes wants to reuse the original body. The syntax for calling a specific interface's default is `InterfaceName.super.methodName(args)`. It mirrors the `super.method()` syntax for calling a superclass method, but with the interface name attached.\n\n\n```java\npublic class CallSpecificParent {\n public static void main(String[] args) {\n AuditedOrderService svc = new AuditedOrderService();\n svc.notifyCustomer(\"Order shipped\");\n }\n}\n\ninterface Notifiable {\n default void notifyCustomer(String message) {\n System.out.println(\"[Notification] \" + message);\n }\n}\n\ninterface Auditable {\n default void notifyCustomer(String message) {\n System.out.println(\"[Audit] \" + message);\n }\n}\n\nclass AuditedOrderService implements Notifiable, Auditable {\n @Override\n public void notifyCustomer(String message) {\n // Audit first, then notify. Order matters for the side effects.\n Auditable.super.notifyCustomer(message);\n Notifiable.super.notifyCustomer(message);\n }\n}\n```\n\n\nTwo notes on the syntax. First, the interface name has to be a direct parent of the class. Reaching two interfaces away with `GrandparentInterface.super.method()` doesn't work. Second, plain `super.method()` (without an interface name) refers to the superclass, not any interface. If the class doesn't extend a non-`Object` superclass, plain `super.method()` looks in `Object`, which is rarely the intended target.\n\nA common mistake is forgetting the `.super` part:\n\n**What's wrong with this code?**\n\n\n```java\nclass AuditedOrderService implements Notifiable, Auditable {\n @Override\n public void notifyCustomer(String message) {\n Auditable.notifyCustomer(message); // compile error\n }\n}\n```\n\n\n**Fix:**\n\n\n```java\nclass AuditedOrderService implements Notifiable, Auditable {\n @Override\n public void notifyCustomer(String message) {\n Auditable.super.notifyCustomer(message);\n }\n}\n```\n\n\nWithout `.super`, `Auditable.notifyCustomer(message)` looks like an attempt to call a `static` method on the interface, which doesn't exist. The compiler reports `non-static method notifyCustomer(String) cannot be referenced from a static context`. The `.super` keyword selects the instance default method of this interface, called on the current object.\n\n---\n\n# Default Methods Can't Override `java.lang.Object`\n\nThere's one specific limit on what a default method can do: it can't override the methods that every class inherits from `java.lang.Object`. That means no `default String toString()`, no `default boolean equals(Object o)`, and no `default int hashCode()` on an interface. Java forbids this at the language level.\n\n\n```java\n// THIS DOES NOT COMPILE.\ninterface BadInterface {\n default String toString() {\n return \"from interface\";\n }\n}\n```\n\n\nThe compiler error reads:\n\n\n```shell\nerror: default method toString in interface BadInterface overrides a member of java.lang.Object\n default String toString() {\n ^\n```\n\n\nThe rule is not arbitrary. Every class already inherits a working `toString()`, `equals()`, and `hashCode()` from `Object`. If interfaces could ship their own defaults for these, the resolution rules would have to answer a hard question: when a class inherits `toString()` from `Object` (a class) and from an interface (a default), which wins? Rule 1 says class wins, which would mean the interface's `toString` is always ignored without warning. That is error-prone: a `default toString()` would be expected to take effect and never would.\n\nJava's designers cut the knot. Interfaces simply can't declare defaults for `Object` methods. For a custom `toString()` shared across all implementers of an interface, two options remain: provide an abstract class that implements the interface and overrides `toString()`, or accept that each implementing class needs to override `toString()` itself.\n\n---\n\n# Default Methods and the Single-Abstract-Method Rule\n\nA **functional interface** is an interface with exactly one abstract method, which makes it usable as a lambda target. Default methods don't count toward that single-abstract-method rule. An interface can have one abstract method and ten default methods and still be a valid functional interface. The main point here is that adding default methods doesn't break the SAM rule.\n\n---\n\n# A Realistic Example: Notification Channels\n\nHere's a more substantial example. An e-commerce app sends notifications about orders through different channels (email, SMS, push). Each channel implements a small set of abstract methods, and the interface ships rich default behavior on top.\n\n\n```java\npublic class NotificationDemo {\n public static void main(String[] args) {\n NotificationChannel email = new EmailChannel(\"alice@example.com\");\n NotificationChannel sms = new SmsChannel(\"+1-555-0100\");\n\n email.notifyOrderShipped(\"ORD-9381\");\n sms.notifyOrderShipped(\"ORD-9381\");\n }\n}\n\ninterface NotificationChannel {\n String channelName();\n\n void send(String recipient, String message);\n\n String recipient();\n\n default void notifyOrderShipped(String orderId) {\n String message = \"Your order \" + orderId + \" has shipped.\";\n send(recipient(), formatted(message));\n }\n\n default String formatted(String message) {\n return \"[\" + channelName() + \"] \" + message;\n }\n}\n\nclass EmailChannel implements NotificationChannel {\n private String email;\n\n public EmailChannel(String email) {\n this.email = email;\n }\n\n @Override\n public String channelName() {\n return \"Email\";\n }\n\n @Override\n public String recipient() {\n return email;\n }\n\n @Override\n public void send(String recipient, String message) {\n System.out.println(\"To \" + recipient + \": \" + message);\n }\n}\n\nclass SmsChannel implements NotificationChannel {\n private String phone;\n\n public SmsChannel(String phone) {\n this.phone = phone;\n }\n\n @Override\n public String channelName() {\n return \"SMS\";\n }\n\n @Override\n public String recipient() {\n return phone;\n }\n\n @Override\n public void send(String recipient, String message) {\n System.out.println(\"Text \" + recipient + \": \" + message);\n }\n}\n```\n\n\nEach channel implements three small methods: `channelName()`, `recipient()`, and `send(...)`. The interface builds the higher-level `notifyOrderShipped(...)` and `formatted(...)` defaults on top of them. Adding a `PushChannel` later only requires implementing those three methods; the rest comes from the interface. A channel that formats messages differently can override `formatted(...)` without touching `notifyOrderShipped(...)`.\n\nThis is the same template-method pattern an abstract class would provide. The difference is reach: a class can only extend one abstract class, but it can implement many interfaces. `EmailChannel` is free to extend some unrelated class (a base `Service`, say) and still pick up the notification template by implementing `NotificationChannel`.\n\n---\n\n# When to Use Default Methods and When Not To\n\nDefault methods are powerful, and like most powerful tools, they pay off in a few specific situations and create mess everywhere else. A reasonable guide:\n\n**Use default methods when:**\n\n- Evolving a public interface where adding a new method would break every existing implementer. This is the original motivation.\n- Layering common behavior on a small set of abstract methods, like the `priceSummary()` example. Each implementer writes the minimum; the interface fills in the rest.\n- Template-method behavior is wanted without forcing implementers into a particular class hierarchy.\n\n**Avoid default methods when:**\n\n- State is needed. Interfaces have no fields. A default method can't store anything between calls. An `int counter` calls for an abstract class, not an interface.\n- The behavior is non-trivial and shared by everything. An abstract class is usually clearer because it can hold helper fields and have a constructor.\n- The default is just a placeholder so implementers don't have to write the method. That's a code smell; the implementers probably do need to think about it, and a default-with-empty-body just hides the question.\n\nDefault methods are an interface evolution mechanism first and a \"free behavior\" mechanism second. Treat the second use carefully.\n\n---\n\n# Performance Notes\n\nA default method call uses the JVM's `invokeinterface` bytecode (the same one used for any interface call) and goes through the same method-table lookup that interface methods always have. Once the JIT decides a particular call site is monomorphic (only one implementing class shows up), it inlines the method body directly and the dispatch disappears.\n\nThe cost difference between an abstract method call on an interface and a default method call on an interface is zero. They both compile to `invokeinterface`, they both look up the same way, and they both inline when the JIT can prove it is safe. The only thing the `default` keyword changes is what happens when the implementing class does not provide the method: it falls back to the interface's body instead of failing.\n\nDo not avoid default methods on performance grounds. The dispatch cost is the same as any other interface method call, which is the same as any other virtual call. Optimize for clarity; profile before assuming.","pageType":"java"}

Default Methods

Get Premium