Static and default methods in interfaces

This topic sits right where interviewers like to dig. The surface question is easy ("what's a default method?"), and then come the follow-ups: which method runs when a superclass and an interface both provide one, what happens with two interfaces that disagree, why can't a default method override equals, and why Impl.staticMethod() doesn't compile when it would for a class. Those rules are short, but candidates who memorised "interfaces have no code" stumble on every one of them.

For this lesson, we'll focus on why Java 8 added default and static methods, the three resolution rules and the X.super.m() syntax, the diamond cases, static methods not being inherited, private helpers, and the binary-compatibility trap that can turn a library upgrade into a runtime error.

01Picture it first: a franchise manual with house rules

Think of a restaurant franchise. Head office sends every outlet a manual: "greet customers like this, plate the dessert like that". An outlet can follow the manual or write its own version of any step. If the outlet's owner already has a rule for that step, the owner's rule wins, because the outlet is the one actually doing the work. If two head offices (say a food franchise and a coffee franchise sharing one shop) send conflicting rules for the same step, the shop owner has to decide, and can say "for this one, I'll follow the coffee manual".

That's the default-method model. The interface ships a default body; the class can override it; the class's own hierarchy wins over any interface; and when two interfaces clash, the class must decide explicitly. The flowchart below is the whole resolution algorithm, and it's worth being able to draw it from memory.

Fig. 1

A decision flowchart for which method body runs: if the class or any superclass declares the method, that wins; otherwise if one interface's version overrides all the others, the most specific interface wins; otherwise compilation fails until the class overrides the method, optionally delegating with A.super.m()

Notice that the first question is about classes, including abstract methods in a superclass. Interfaces only get a say once the class hierarchy has nothing to offer.

02Default and static methods under the hood

Why Java 8 needed them

Before Java 8, adding a method to a published interface broke every implementation: class MyList implements List would stop compiling, and an old compiled MyList.class would throw AbstractMethodError the first time someone called the new method. That made lambdas almost unusable, because the whole point was to write orders.stream().filter(...) and orders.forEach(...) on collections that already existed. Default methods let the JDK add stream(), forEach(), removeIf(), List.sort(), Map.getOrDefault(), Map.computeIfAbsent() and dozens more, each with a body written in terms of methods every implementation already had.

// Roughly how the JDK declares it (simplified)
public interface Collection<E> extends Iterable<E> {
    Iterator<E> iterator();
    int size();

    default Stream<E> stream() {
        return StreamSupport.stream(spliterator(), false);
    }

    default boolean removeIf(Predicate<? super E> filter) {
        boolean removed = false;
        for (Iterator<E> it = iterator(); it.hasNext(); ) {
            if (filter.test(it.next())) { it.remove(); removed = true; }
        }
        return removed;
    }
}

The default removeIf works for any collection through iterator(), and ArrayList overrides it with a faster array-based version. That's the pattern: a correct default in terms of the abstract methods, and optional overrides for speed.

The diagram below shows why adding a default method changed interface evolution from a breaking change into a compatible upgrade.

Fig. 2

A published interface before Java 8 breaks existing implementers when a method is added, while Java 8 and later can add a default body so old implementers keep linking and may override later

The three resolution rules in code

interface Notifier {
    default String send(String userId) { return "email to " + userId; }
}
interface SmsNotifier extends Notifier {
    @Override default String send(String userId) { return "sms to " + userId; }
}
class BaseService {
    public String send(String userId) { return "base to " + userId; }
}

class OrderService extends BaseService implements Notifier {}     // rule 1: class wins
class AlertService implements Notifier, SmsNotifier {}            // rule 2: more specific wins

interface Logger  { default String tag() { return "log"; } }
interface Metrics { default String tag() { return "metrics"; } }
class Telemetry implements Logger, Metrics {                      // rule 3: must override
    @Override public String tag() {
        return Logger.super.tag() + "+" + Metrics.super.tag();
    }
}

System.out.println(new OrderService().send("u1"));   // prints: base to u1
System.out.println(new AlertService().send("u1"));   // prints: sms to u1
System.out.println(new Telemetry().tag());           // prints: log+metrics

Notice three things:

• Rule 1, class wins. OrderService inherits send from BaseService and a default from Notifier. The superclass method wins, even though BaseService has nothing to do with Notifier. This rule also applies to abstract superclass methods: if BaseService.send were abstract, OrderService would have to implement it, and the default wouldn't fill the gap.
• Rule 2, more specific interface wins. SmsNotifier extends Notifier and overrides send, so for AlertService the SmsNotifier version is "more specific". Listing Notifier explicitly in the implements clause changes nothing.
• Rule 3, explicit choice. Logger and Metrics are unrelated. Delete Telemetry.tag() and javac reports types Logger and Metrics are incompatible; class Telemetry inherits unrelated defaults for tag() from types Logger and Metrics. The Logger.super.tag() syntax calls a specific interface's default, and it compiles to invokespecial on an InterfaceMethod reference.

X.super.m() has two restrictions interviewers like. X must be a direct superinterface of the class, and you can't use it to skip past a more specific override: if class Q implements PushNotifier, Notifier and PushNotifier overrides Notifier's default, then Notifier.super.send(...) fails with bad type qualifier Notifier in default super call.