The$diamond$problem:$multiple$inheritance$
Google “diamond problem” and you will get a bunch of websites that talk about the diamond
problem in OO languages, showing a diamond like that drawn to the right. It shows classes or inter-
faces (Java terminology) A, B, C, and D, with (1) B and C extending or implementing A and (2) D ex-
tending or implementing both B and C. The diamond problem has to do with multiple inheritance. If
both B and C declare a method m and D calls m, which method should be called, the one in B or the one
in C? This question has to be answered in some unambiguous way.
Multiple inheritance is an issue not just in Java but in many OO languages like C++, Common Lisp, C#, Eiffel,
Go, OCaml, Perl, Python, Ruby, and Scala. Each OO language solves the ambiguity in some way.
We show you how Java handles the diamond problem in Java, talking a bit about its history. For
many Java cases, it’s not a diamond problem, it’s a Vee problem. Only B, C, and D are needed to
explain some issues. At the end, we show you a diamond problem.
1. B, C, and D are classes
The program to the right is not a legal Java program because class
D may extend only one class, and here it extends both B and C. But if it
were legal, it would be ambiguous because in class D, it is not known
which method m to call, the one inherited from class B or the one inher-
ited from class C. Java avoids the multiple inheritance problem for
classes by allowing a class to extend only one other class.
2. B, C are interfaces and D is a class, in version 7 or less
Class D can implement many interfaces. To the right, it imple-
ments both B and C. Further, in Java 7 and earlier, all methods in an
interface are abstract, and any non-abstract class that implements the
interface must override interface’s abstract methods. The interface
defines only the syntax of calls on a method, so there is no ambiguity.
3. B and D are classes and C is an interface, in version 7 or less
To the right, class B declares method m and interface C declares
abstract m. Since D inherits m from B, D need not declare m again; it is
already available. There is no ambiguity here because interface C de-
fines only the syntax of calls on m.
Suppose B does not declare m to be public. Then there is a syntax
error: inherited method m cannot hide public abstract method m in C.
There is a choice: either have m in B be public or declare public meth-
od m in D.
4. Default interface methods in Java version 8
Version 8 of Java, released in Spring 2014, allowed default
methods in interfaces, as shown to the right. Since interface C has a
default method m, class D does not have to override m; if it doesn’t,
the default method is used.
Ah, but now we have a problem. With the classes and interfac-
es shown to the right, what method m will be called in method D.p?
The one in class B or the one in interface C?
For backward compatibility ( a Java 7 program should run in
Java 8) the Java designers ruled that the method in B should be
called: the superclass has precedence over the interface.
A$
D$
B!
C$
D$
B!
C$
class B { int m() {return 0;} }
class C { int m() {return 1;} }
class D extends B, C {
void p() {System.out.println(m());}
}. // not legal Java
interface B { int m(); }
interface C { int m(); }
class D implements B, C {
void p() {System.out.println(m());}
public int m() {return 5;}
}
class B { public int m() {return 0;} }
interface C { int m(); }
class D extends B implements C {
void p() {System.out.println(m());}
}
interface C { default int m() {return 1;}}
class D implements C {
void p() {System.out.println(m());}
}
class B { public int m() {return 0;} }
interface C { default int m() {return 1;}}
class D extends B implements C {
void p() {System.out.println(m());}
}
