Java : If A extends B and B extends Object, is that multiple inheritance

My answer is correct?

Yes, mostly, and certainly in the context you describe. This is not multiple inheritance:

Object ^- ClassA ^- ClassB

It’s what you said it is, single inheritance with multiple levels.

This is multiple inheritance: Inheriting from two or more bases that don’t have any “is a” relationship with each other; that would be inheriting from unrelated lines, or from lines that had previously diverged (in Java, since Object is always a base, it would be the latter):

Object ^- ClassA, Object ^- ClassB, ClassA ^- ClassC, ClassB ^- ClassC

(Image credits: http://yuml.me in “scruffy” mode)

Internally What happens actually?

Just what you said: There are multiple levels. When the compiler is resolving a member on an instance:

obj.member

…it looks to see if the type of obj (which in this case is a class, say ClassB) has member, either because it provides it directly or it has it through inheritance. At runtime, the JVM uses the member the object actually has.


The reason I said “mostly” above is that Java has interfaces, and as of Java 8 it has “default methods” on interfaces. This complicates things a bit, but your answer about levels is correct in the context of what you described the interviewer saying about Object, ClassA, and ClassB.

Interfaces have always made it possible, in Java, for something to have an “is a” relationship with two different types: A class type it inherits from, and any of several interface types it implements. Interfaces without default methods aren’t multiple inheritance in a practical way (the class has to provide the implementation), but they did make it possible for a class to have multiple “is a” relationships from unrelated type trees. (I’m not an academic, it’s possible an academic would argue that they provide multiple inheritance in an academic way.)

With Java 8, interfaces can provide default implementations of the methods they define, which really blurs the lines even at the practical level. Let’s look at that a bit more deeply:

Say we have ClassA:

class ClassA {
    void doSomething() {
        // Code here
    }
}

and Interface1:

interface Interface1 {
    default void doSomethingElse() { // Requires Java 8
        // Code here
    }
}

and finally ClassB:

class ClassB extends ClassA implements Interface1 {
}

ClassB inherits the implementation of doSomething from ClassA. But it also gets the “default” version of doSomethingElse from Interface1. We didn’t implement it in ClassB, but ClassB isn’t abstract: It really has doSomethingElse. It gets it from the interface. I used the word “gets” rather than “inherits” there, but this looks a lot like inheriting the default method.

This is basically multiple-inheritance “light” (as in “light beer”). It does an end-run around the thornier problems with true multiple inheritance, like:

  • What should the type of super be? (Java 8’s answer: ClassA)
  • What order do you run constructors in? (Java 8’s answer: Single-lineage constructor chaining, interfaces don’t have constructors.)
  • Do you run constructors that you inherit more than once, more than once? (Java 8’s answer: You can’t inherit constructors more than once, interfaces don’t have them.)
  • What happens if you inherit multiple methods with the same signature? (Java 8’s answer: If one of them is from the base class, that’s the one that’s used; a base class’s implementation can override the default method of multiple interfaces. If you have multiple default methods with the same signature from different interfaces at compile-time, it’s a compile-time error. If an interface has been changed without the class being recompiled and the situation arises at runtime, it’s a runtime IncompatibleClassChangeError exception listing the conflicting default methods.)

Leave a Comment