Why Does Java Ban Multiple Inheritance?

Because inheriting from two classes means inheriting two sets of state, and when the two sets overlap the language has no good answer. Imagine a class extending both A and B, where each declares a field called size. The subclass inherits two distinct fields, occupying two separate places in the object layout. Reading size is ambiguous, and assigning to one of them leaves the other untouched — so the object holds two different answers to the same question with no way for a caller to tell which one they got.

That is not a hypothetical. Languages that allow multiple inheritance of classes — C++, Python, Ruby — all had to add explicit qualification syntax so you can say which superclass's member you mean, and they all have rules about what happens when the diamond is implicit. The complexity is real and it lands in the code, not just in the language definition.

Java's answer is to split the two concerns. State — fields, constructors — comes from a single superclass, so there is never ambiguity about storage. Behaviour — method contracts — comes from any number of interfaces, and because an interface carried no fields historically, two interfaces declaring the same method were harmless: one implementation satisfied both.

public class Main {
    public static void main(String[] args) {
        // One superclass, several interfaces: no conflict.
        Dog dog = new Dog();
        System.out.println("dog name  : " + dog.name());
        System.out.println("dog pets  : " + dog.pets());
        System.out.println("dog trains: " + dog.train());
    }
}

class Animal {
    public String name() {
        return "animal";
    }
}

interface Pet {
    default String pets() {
        return "being a good pet";
    }
}

interface Trainable {
    default String train() {
        return "learning tricks";
    }
}

class Dog extends Animal implements Pet, Trainable {
    @Override
    public String pets() {
        return "being a good dog";
    }
}

The output shows the practical result: a Dog is an Animal by inheritance, a Pet and a Trainable by interface, and there is no conflict anywhere. When you genuinely need behaviour from two unrelated hierarchies, Java's idiom is composition: hold the other object as a field and delegate to it.

The diamond is a shape in an inheritance graph: one type at the top, two types below it, and one type at the bottom that inherits from both. Originally the bottom type had no problem, because interfaces carried no implementation — a method declared at the top was abstract and the bottom class implemented it once.

Giving interfaces default methods reintroduced the diamond for behaviour. If Top supplies a default describe() and both Left and Right inherit it unchanged, then Bottom extends Left, Right has two competing inherited implementations of the same method and no obvious winner. The compiler refuses to compile it.

Java resolves it with a set of rules. If only one of the conflicting superinterfaces provides an override, that one wins — the most specific method is inherited. If two unrelated interfaces both override it, the class must override it and resolve the conflict explicitly. And if the conflict is between a class and an interface, the class wins.

public class Main {
    public static void main(String[] args) {
        System.out.println("diamond : " + new DiamondImpl().describe());
        System.out.println("merged  : " + new MergedImpl().describe());
    }
}

interface Top {
    default String describe() {
        return "top";
    }
}

interface Left extends Top {
    @Override
    default String describe() {
        return "left";
    }
}

interface Right extends Top {
    @Override
    default String describe() {
        return "right";
    }
}

// Left and Right both override describe(), so the conflict is resolved here.
interface Diamond extends Left, Right {
    @Override
    default String describe() {
        return "diamond";
    }
}

// QuietRight does not override it, so Top's version is inherited unchanged.
interface QuietRight extends Top {
}

// Left's describe() is more specific than Top's, so it wins automatically.
interface Merged extends Left, QuietRight {
}

class DiamondImpl implements Diamond {
}

class MergedImpl implements Merged {
}

The output shows both cases. The Diamond interface had to override the method because two unrelated subinterfaces each supplied one, so it prints diamond. The Merged interface needed no override at all, because Left's version is more specific than the Top version that QuietRight inherits, and it prints left.

This is why the guidance about default methods is: use them for genuinely universal behaviour, not as a convenient place to park shared implementation. When two unrelated hierarchies need the same code, an abstract class or composition is the cleaner answer, because the ambiguity is resolved once at compile time rather than at every call site.

With composition: hold a reference to the other object as a field and delegate the calls you need to it. If you want behaviour from a Car and from a TollTracker, a class can hold both rather than pretending to be a kind of both.

The idiom looks like this: instead of class SportsCar extends Car implements TollTracker with a copied implementation of tolling, you write a class that has a TollTracker field and forwards to it. The behaviour is reused because the other object owns it, not because you copied it.

The trade-offs are honest. Composition costs an extra object and an extra indirection on every delegated call, so it is marginally slower than inheritance, and the caller has to construct the collaborator and hand it in. It also does not give you instanceof transparency — a composed object is not an instance of the thing it delegates to — and it changes the mental model, because the relationship is has-a rather than is-a. On the other hand, composition is far more flexible: the collaborator can be swapped at run time, which is impossible with a superclass fixed at compile time.

There is one more Java-specific tool worth mentioning: default methods on interfaces, which let you share a small amount of behaviour across unrelated types without forcing them into a hierarchy. When the shared code is small and genuinely universal, that is elegant. When it is substantial, the general guidance is to extract it into a helper class and use composition, rather than building a deep inheritance tree to share it.