What Types of Inheritance Does Java Support?

Java supports four of the five textbook forms, and bans the fifth for classes.

Single inheritance: a class extends exactly one superclass. This is the standard form — class Dog extends Animal.

Multilevel inheritance: a chain of classes, each extending the one before. Puppy extends Dog extends Animal. This is legal and extremely common in older code, though it produces the deep hierarchies discussed later in this topic.

Hierarchical inheritance: several subclasses sharing one superclass. Dog extends Animal and Cat extends Animal. This is the shape that makes polymorphism useful — a collection of the shared supertype holding different subtypes.

Multiple inheritance of interfaces: a class may implement any number of interfaces. class Dog extends Animal implements Pet, Trainable.

The form Java does not support is multiple inheritance of classes — a class cannot extend two superclasses. The reason is ambiguity: if both superclasses define a method, which one does the subclass inherit? The answer would have to depend on the order of the extends clause, which makes code brittle. Java's answer to that ambiguity is that classes inherit state, and state is where the ambiguity hurts.

There is one more form often mentioned that Java does not support directly: interface-to-interface multiple inheritance, where an interface extends several interfaces. Java does allow this — interface Diamond extends Left, Right — and it is where the interesting default-method rules live.

All three forms are expressed with the same extends keyword, and the difference is purely in the shape of the class graph. Let me build all three at once.

public class Main {
    public static void main(String[] args) {
        // Hierarchical: Dog and Cat both extend Animal.
        Animal a = new Dog();
        System.out.println("dog sound   : " + a.speak());
        System.out.println("dog legs    : " + a.legs());

        // Multilevel: a Puppy is a Dog is an Animal.
        Animal b = new Puppy();
        System.out.println("puppy sound : " + b.speak());

        System.out.println("cat sound   : " + new Cat().speak());
    }
}

class Animal {
    int legs() {
        return 4;
    }

    String speak() {
        return "...";
    }
}

class Dog extends Animal {
    @Override
    String speak() {
        return "woof";
    }
}

class Puppy extends Dog {                 // multilevel inheritance
    @Override
    String speak() {
        return "yip";
    }
}

class Cat extends Animal {               // hierarchical inheritance
    @Override
    String speak() {
        return "meow";
    }
}

The output shows the rule in action. The variable a is declared as an Animal but holds a Dog, so calling speak runs the Dog implementation — that is polymorphic dispatch, and it works identically for the multilevel case where a Puppy overrides the behaviour it inherited from Dog. The legs method is not overridden by Dog, so it is inherited unchanged from Animal.

Two things about what the compiler allows. A subclass inherits everything it does not override or hide, including package-private members when it is in the same package. And an override must respect the rules: same name and parameters, a compatible return type, and an access modifier that is not more restrictive. Anything that fails those is a compile error, not a silent behaviour change.

The practical advice that usually follows from this is to keep hierarchies shallow. Multilevel chains work, but every level adds a layer of indirection that a reader has to follow, and a change deep in the base class ripples outwards to every descendant.

Because classes carry state and interfaces carry behaviour, and ambiguity is much more dangerous when you are inheriting data.

Imagine a class that extended both A and B, where each declared a field called size. The subclass would have two inherited fields with the same name, and reading size would be ambiguous. Worse, the two fields occupy two separate places in the object layout, so the object has two different answers to the question "what is the size?" — and a subclass method that assigns to one of them silently does nothing to the other. That is not a theoretical problem; it is a genuine source of bugs that every language with multiple inheritance of classes has had to solve, usually by adding explicit qualification syntax that makes the code noisy.

Interfaces sidestep this because, historically, they carried no fields — only method contracts. Two interfaces could both declare the same method signature, and the implementing class would supply one implementation that satisfies both. There was nothing to disambiguate because there was no inherited state.

Allowing default methods in interfaces changed that slightly, which reintroduces a form of the diamond problem — but only for behaviour, and the language resolves it with rules: the most specific method wins, and if two unrelated interfaces provide conflicting defaults the implementing class must override and resolve it explicitly. That is a far milder problem than two inherited fields disagreeing.

The alternative Java offers is composition. If you need behaviour from two unrelated hierarchies, hold a reference to the other object as a field and delegate to it, rather than pretending one class is a kind of the other.