Diamond Problem in OOP: How Java Solves It and How ABAP Compares

In Java, the diamond problem means a class can inherit the same member through two different paths, creating ambiguity.

A simple shape of it looks like this:

        A
       / \
      B   C
       \ /
        D

If B and C both inherit from A, and D inherits from both B and C, then the question is:

Which version of A should D get?

This is the classic problem in languages that allow multiple inheritance of classes.

How Java avoided it

Java solved it first by not allowing multiple inheritance of classes at all.

So this is illegal in Java:

class A {}
class B extends A {}
class C extends A {}

// Not allowed in Java
class D extends B, C {}

Because of that, the classic diamond problem for classes never happens in Java.

But later Java introduced a limited version

When Java 8 introduced default methods in interfaces, a smaller form of the diamond problem became possible again.

Example:

interface A {
 default void hello() {
  System.out.println("Hello from A");
 }
}

interface B extends A {}

interface C extends A {}

class D implements B, C {
}

This is still fine, because both paths lead to the same inherited default from A.

But now look at this:

interface B {
 default void hello() {
 System.out.println("Hello from B");
 }
}

interface C {
 default void hello() {
 System.out.println("Hello from C");
 }
}

class D implements B, C {
}

Now Java says: ambiguous.

You must override it:

class D implements B, C {
 @Override
 public void hello() {
   B.super.hello(); / or C.super.hello() / or your own logic
 }
}

Java’s rules for resolving it

When Java sees multiple possible implementations of the same method, it follows a priority system.

1. Class wins over interface - Real implementation (class) beats default suggestion (interface)

If a superclass already has the method, that method is used instead of interface default methods.

class A {
    public void hello() {
        System.out.println("Hello from class A");
    }
}

interface B {
    default void hello() {
        System.out.println("Hello from interface B");
    }
}

class D extends A implements B {
}

• D.hello() uses the class version from A.

2. More specific interface wins - If interfaces are related, choose the more specialized one

If one interface extends another, the more specific one is chosen.

interface A {
 default void hello() {
 System.out.println("Hello from A");
 }
}

interface B extends A {
 default void hello() {
 System.out.println("Hello from B");
 }
}

class D implements B {
}

• B extends A -> so B is more specific

• Both have hello()

• A = general rule

• B = specialized rule

Always pick more specific knowledge

D says

Hello from B

3. If Java gets confused, it forces you to resolve it

interface B {
 default void hello() {
 System.out.println("Hello from B");
 }
}

interface C {
 default void hello() {
 System.out.println("Hello from C");
 }
}

class D implements B, C {
}

X Compile error

FIX:

class D implements B, C {
 @Override
 public void hello() {
  B.super.hello(); / or C.super.hello()
 }
}

Priority Order

1. Class method (highest priority)

2. More specific interface

3. Otherwise -> force override

How ABAP resolves it

INTERFACE zif_a.
 METHODS hello.
ENDINTERFACE.

INTERFACE zif_b.
 INTERFACES zif_a.
ENDINTERFACE.

INTERFACE zif_c.
 INTERFACES zif_a.
ENDINTERFACE.

CLASS zcl_d DEFINITION.
 PUBLIC SECTION.
 INTERFACES zif_b.
 INTERFACES zif_c.
ENDCLASS.

Key difference from Java:

ABAP interfaces do NOT carry default implementations

So:

• zif_a only declares hello

• zif_b and zif_c just inherit that declaration

• No implementation exists yet

class D must implement the method.

CLASS zcl_d IMPLEMENTATION.

 METHOD zif_a~hello.
  WRITE: 'Hello from D'.
 ENDMETHOD.

ENDCLASS.

Even though zif_b and zif_c both include zif_a ABAP sees only one method contract

zif_a~hello

So:

• No duplication

• No ambiguity

• Only one implementation required

Why no diamond problem in ABAP?

There is no inherited implementation, only method definitions

In Java, interfaces can “bring behavior,” so conflicts can happen.

In ABAP, interfaces only “define behavior,” so the class must implement it hence no conflict ever arises.

ABAP avoids the diamond problem entirely because interfaces do not provide implementations; they only define method signatures, so the implementing class provides a single concrete implementation, eliminating ambiguity.

In Java, interfaces can include actual behavior through default methods, which means a class can inherit implementations from multiple interfaces—this is why diamond conflicts can arise at the interface level and require Java’s resolution rules to handle ambiguity. In contrast, ABAP interfaces only define method signatures and do not provide implementations, so no such conflict occurs. Instead, the responsibility is always on the developer to implement the method explicitly in the class, ensuring there is a single, clear implementation. As a result, in Java a method may be inherited or overridden depending on the situation, whereas in ABAP the final implementation always resides in the class itself.