Interfaces in Java: Contracts, Multiple Inheritance, and Default Methods

An interface describes what a type must be able to do, and nothing about how it stores or computes anything. It holds no instance state and no constructor, so you cannot create an object of an interface any more than you can create one of an abstract class.

interface Payable {
    int CURRENCY = 840;
    long amountOf();
    String currency();
    void pay(long amount);
}

None of those modifiers are written, because every one of them is implied. Reflection confirms what the compiler actually stores:

Method m = Payable.class.getMethod("currency");
Modifier.toString(m.getModifiers());
// "public abstract"
Field f = Payable.class.getDeclaredField("CURRENCY");
Modifier.toString(f.getModifiers());
// "public static final"

So interface methods are public abstract and interface fields are public static final. Writing those keywords by hand is legal but redundant. The one thing you cannot do is narrow any of it, which is why every implementor is obliged to publish the method publicly.

A class may extend exactly one class, because a class carries state and there is no defensible way to combine two copies of it. A class may implement any number of interfaces, because an interface carries only a promise, and two promises can be combined without conflict.

final class CardPayment implements Payable, Auditable, Serializable {
    // three contracts, one object
}

This is where the phrase "multiple inheritance" comes from, and it is worth being precise about what is inherited. Java inherits the type and the contract from several interfaces. It does not inherit state or implementation from several sources, and the diamond problem that plagues C++ simply does not arise for that reason.

Interfaces may also extend other interfaces, which lets you build up a hierarchy of promises:

interface Closeable2 extends AutoCloseable {
} // AutoCloseable has one abstract method

Before Java 8 every interface method had to be abstract, which created a genuine versioning trap. Adding a method to an interface meant every existing implementor had to be found and updated, and any one missed was a compile error.

interface PayableV1 {
    long amountOf();
}// v2 adds a new ABSTRACT method. ModernPayment now fails to compile:
interface PayableV2 extends PayableV1 {
    String currency();
}// error: ModernPayment is not abstract and does not override
//        abstract method currency() in PayableV2

A default method removes that trap, because it arrives with an implementation:

interface PayableV2 extends PayableV1 {
    default String currency() {
        return "UNKNOWN";
    }
}

Now ModernPayment compiles untouched. Implementors that care override the method; implementors that do not inherit a sensible fallback. This is not a theoretical concern. Iterable.forEach, Collection.removeIf, List.sort, and Comparator.reversed are all default methods added to interfaces that already had thousands of implementors, and every one of them compiled without a single downstream change.

Overriding is genuinely optional, which is the point:

interface Auditable {
    long amountOf();
    default String auditTrail() {
        return "amount " + amountOf();
    }
}final class CardPayment implements Auditable {
    public long amountOf() {
        return 1200;
    } // auditTrail() is inherited unchanged
}

Once a default method exists, a class can inherit several candidates for the same signature, and javac resolves that with three rules applied in order.

Rule 1: the class wins. A method written on the implementing class always overrides an interface default. No conflict is reported, because there is nothing ambiguous about it.

interface A {
    default void go() {
        System.out.println("A");
    }
}class C implements A {
    @Override public void go() {
        System.out.println("class wins");
    }
}// prints "class wins"

Rule 2: the most specific interface wins. When one interface extends another and both declare the method, the subinterface is more specific and its version is used. Still no error.

interface A2 {
    default void go() {
        System.out.println("A");
    }
}interface B2 extends A2 {
    default void go() {
        System.out.println("B, more specific");
    }
}class C2 implements B2 {
}// prints "B, more specific", and C2 needs no method of its own

Rule 3: unrelated interfaces are a conflict. This is the case people actually hit. When two interfaces that do not extend each other both declare the same default, there is no principled winner, so the compiler refuses to choose.

interface A3 {
    default void go() {
        System.out.println("A");
    }
}interface B3 {
    default void go() {
        System.out.println("B");
    }
}class Both implements A3, B3 {
}// error: types A3 and B3 are incompatible;
//        class Both inherits unrelated defaults for go() from types A3 and B3

There are exactly two ways out, and both put the decision back in your hands.

class Decides implements A3, B3 {
    @Override public void go() {
        // option 1: decide for yourself
        System.out.println("mine");
    }
}class Delegates implements A3, B3 {
    @Override public void go() {
        // option 2: delegate to one parent
        A3.super.go();
    }
}

One restriction catches people: a qualified super call works only on a direct parent interface. If B extends A, a class implementing only B cannot write A.super.go(), and gets "not an enclosing class" instead.

Java 8 added static methods to an interface. These are utility methods that belong to the interface's own namespace and are never inherited, so they cannot be called through an implementing class or a reference.

interface Payables {
    static Payable of(long amount) {
        return new CardPayment(amount, false);
    }
}long AMOUNT = 500;
Payable p = Payables.of(AMOUNT);
// correct
Payable q = p.of(AMOUNT);
// compile error, not inherited

Java 9 added private methods, which solve a problem defaults created: two default methods often need to share a helper, and without private that helper would have to be public and become part of the interface's contract.

interface Auditable2 {
    private static String normalise(long v) {
        return v 

normalise and stamp are implementation detail. Nobody outside the interface can call them, which is what keeps the public surface small as the interface grows.

An interface with exactly one abstract method is a functional interface, whatever else it contains. The @FunctionalInterface annotation is optional but worth adding, because the compiler then verifies the count for you.

@FunctionalInterfaceinterface Transformer {
    String apply(String input);
    default Transformer twice() {
        // defaults do not count
        return s -> apply(apply(s));
    }
}

Since defaults and statics are excluded from the count, a functional interface may have several of them and still take a lambda:

Transformer t = s -> s + "-";
System.out.println(t.apply("ada"));
// ada-
System.out.println(t.twice().apply("ada"));
// ada--

The default method composes itself, so twice() returns a new Transformer that applies the original twice. Notice the return type: a default method may return the functional interface itself, which is how small reusable combinators are built without a single named class.

This is the mechanism behind the standard library's functional types such as Runnable, Callable, Comparator, and Function, all of which are single-abstract-method interfaces. A default method that throws AbstractMethodError at run time can break the rule at source level, which is precisely why the annotation exists.

Reach for an interface when you are naming what a thing can do and the implementations are genuinely unrelated. Reach for an abstract class when the subtypes share data or a workflow that must be written once.

They are not competitors and both can be used in one hierarchy. An abstract class can implement an interface and leave the methods unimplemented, which is often the cleanest shape when a family shares a base implementation but should also advertise a role.

Interfaces earn their keep when you want to name a capability that unrelated types share. Comparable, AutoCloseable, Serializable, Runnable, and Iterator are all standard-library examples, and each one lets code accept anything that satisfies the contract without knowing the concrete type.

That is the practical test: if your method parameter only ever calls methods declared on the interface, type the parameter as the interface. It keeps callers decoupled and makes the method testable with a small hand-written implementation.

Prefer an abstract class when you have noticed the same fields or the same sequence of calls appearing in three or more subclasses. At that point the duplication is real, and an abstract class moves it somewhere the compiler enforces.

Frequently Asked Questions

What is the difference between an interface and an abstract class in Java?

An interface carries no per-object state and declares no constructor, so it can describe a capability but not an implementation. An abstract class holds fields, runs constructors, and can mix abstract and concrete methods. A class may implement any number of interfaces but extend only one class, which is why interfaces provide multiple inheritance of type without the diamond problem.

Can an interface have instance fields?

No. Every field in an interface is implicitly public static final, so it belongs to the interface rather than to any object and cannot vary per instance. Reflection confirms the modifiers are stored exactly that way. To hold per-object state you need a class, which is the main reason interfaces cannot replace abstract classes.

Why do interface methods not need the abstract keyword?

Because it is implied. An interface method declared with a body is a default method, and one with a static body is a static method, so anything left over is implicitly public abstract. Writing the keywords out is legal and does nothing.

How does Java resolve two default methods with the same name?

Three rules, in order: a method on the implementing class wins; failing that, the most specific interface wins, so a subinterface beats its parent; failing that, if two unrelated interfaces both declare it, the compiler reports an error saying the class inherits unrelated defaults. You then break the tie with an override or a qualified super call such as A.super.go().

Why do default methods exist?

To let an interface gain a method without breaking existing implementors. Adding an abstract method forces every implementation in the world to add the method or fail to compile. Adding a default method brings an implementation with it, so existing code keeps working and only the implementors that want different behaviour override it. This is how Iterable.forEach and Collection.removeIf were added to the JDK.

Can a default method be overridden?

Yes, and it is optional. A class may override a default method exactly as it would override any inherited method, using the same signature rules. When it does not, it simply inherits the interface implementation. Marking the method @Override documents the intent and catches a signature typo.

What is a functional interface?

An interface with exactly one abstract method. Default and static methods do not count towards that total, so a functional interface may contain several of them and still accept a lambda. Adding the @FunctionalInterface annotation is optional but makes the compiler enforce the rule, which is useful because a stray second abstract method is easy to add by accident.

Are interface static methods inherited by implementing classes?

No. They belong to the interface itself and must be called through the interface name, such as Payables.of(AMOUNT). Calling one through an instance or a reference typed as the interface is a compile error, which is what stops static interface methods from colliding with instance methods on the implementing type.

Can an interface extend multiple other interfaces?

Yes, using extends, and the child then inherits every contract from its parents. This is how you build a larger promise out of smaller ones without involving classes. Unlike classes, the reverse is not allowed: an interface cannot extend a class, and asking for it produces "interface expected here".

One detail catches people when chaining interfaces. If the two parents both supply the same default, the conflict appears on the child interface, before any class is involved:

interface P1 {
    default void go() {
    }
}interface P2 {
    default void go() {
    }
}interface P3 extends P1, P2 {
}// error: types P1 and P2 are incompatible;
//        interface P3 inherits unrelated defaults for go() from types P1 and P2

P3 must therefore override go() itself, or declare a fresh default that settles the question for its own implementors.