Default and static interface methods

Written Explanation

A default method

interface Shape {
    double area();
    default String describe() {          // has a body
        return "Area: " + area();
    }
}

Every class that implements Shape receives describe() for free. It can use the abstract method area() because, at run time, the object will be a real class that has written area().

A class may keep the inherited version or override it:

class Disk implements Shape {
    @Override public double area() { ... }
    @Override public String describe() { return "Disk with area ..."; }
}

Note that, like every interface method, a default method is public.

Why Java added them

The Java tutorial explains the purpose: default methods let you add new functionality to an existing interface without breaking classes that already implement it. Without them, a new abstract method would force every implementing class to be rewritten. The library's own Comparator interface gained methods this way.

You can see the effect directly. Suppose Notifier shipped with only send, and ConsoleNotifier was compiled against it. Now the interface gains a default method:

public interface Notifier {
    void send(String to, String message);
    default void sendAll(String[] recipients, String message) {
        for (String r : recipients) send(r, message);
    }
}

ConsoleNotifier needs no change: it already has send, and it gains sendAll automatically. In a test run for this lesson, the old ConsoleNotifier.class file (compiled before the interface changed) worked unmodified with the new interface.

A static interface method

static boolean isValidRecipient(String to) {
    return to != null && !to.isBlank();
}

A static method in an interface belongs to the interface itself. You call it on the interface name: Notifier.isValidRecipient("ana"). Per the Java tutorial it is not inherited by implementing classes, so consoleNotifier.isValidRecipient(...) does not compile. Use static methods for small helpers closely tied to the contract, such as validation or factory-style helpers.

Risks

Risk 1: Conflicting defaults. If a class implements two unrelated interfaces that both supply a default method with the same signature, Java does not guess:

interface Alarm { default String signal() { return "beep"; } }
interface Light { default String signal() { return "flash"; } }
class Device implements Alarm, Light { }

error: types Alarm and Light are incompatible;
  class Device inherits unrelated defaults for signal() from types Alarm and Light

The class must override the method. It can call a chosen version with Alarm.super.signal(). As a rule of thumb from the Java Language Specification: a method inherited from a superclass wins over an interface default, and a default in a more specific sub-interface wins over the one it extends. For unrelated interfaces, you decide.

Risk 2: Logic hides in interfaces. An interface is supposed to be a short contract that you can read in ten seconds. When defaults grow into pages of code, the real behavior is hard to find, and a change in one default silently changes every implementer. A default also cannot use object state, because interfaces have no instance fields, so it can only work through the abstract methods.

Risk 3: A default that is wrong for some class. A default is inherited by every implementer that does not override it. If isFree() is defined as amountDue() == 0, a class where that is the wrong rule silently gets the wrong answer. Unlike an abstract method, forgetting to override produces no error.

When to use a default

Keep interfaces small. If you need fields or a long shared algorithm, the previous lessons already told you the tool: an abstract class.

Default methods and abstract classes

Default methods do not replace abstract classes. An abstract class can hold state and constructors; a default method cannot. They solve different problems: defaults mainly help an interface grow safely.