Java Interface Default Implementations

Since Java 8 we can write implementations into interfaces. As several interfaces can be implemented by a class, a class can now inherit actual code (not just responsibilities) from multiple different sources. Such inherited default implementations are overridable, and multiple-inheritance problems will detected and rejected by the Java 8 compiler.

Example

The interface Identified demands the presence of an identifier like a database primary key.
The interface Named demands the presence of a human readable name.
Objects of the example class Person should be both identified and named.


    public static void main(String[] args) {
        Person person = new Person(1L, "John Doe");
        System.out.println("Person id="+person.getId()+", name="+person.getName());
    }

Before Java 8

It was not possible to provide a default implementation of an interface responsibility, all implementations had to be in the class:

public interface Identified
{
    Object getId();
}

public interface Named
{
    String getName();
}

public class Person implements Identified, Named
{
    private final Object identity;
    private final String name;
   
    public Person(Object identity, String name)   {
        this.identity = identity;
        this.name = name;
    }
   
    @Override
    public Object getId() {
       return identity;
    }

    @Override
    public String getName() {
       return name;
    }
}

Since Java 8

In case the inherited interface responsibility happens to be optional, we can now provide a default implementation for any interface method:

public interface Named
{
    default String getName() {
        return "(undefined name)";
    }
}

public interface Identified
{
    default Object getId() {
        return null;
    }
}

As both interfaces provide defaults, the inheriting class is not required to implement anything:

public class Person implements Identified, Named
{
}

Overriding Defaults

Most important here: default implementations can be overridden (other than static ones). In the Person example this actually makes sense. Following source shows an implementation that redirects getId() to the according constructor parameter:

public class Person implements Identified, Named
{
    private final Object identity;
   
    public Person(Object identity)   {
        this.identity = identity;
    }
   
    @Override
    public Object getId() {
       return identity;
    }
}

Conflict Solution

The "diamond problem" occurs in case two inherited interfaces provide a default method of same signature:

public interface Identified
{
    default boolean isDeleted() {
        return false;
    }
    
    ....
}

public interface Named
{
    default boolean isDeleted() {
        return true;
    
    ....
}

The isDeleted() method has been introduced on both interfaces, with different default implementations. Which one would be used at runtime by Person?

We don't need to think about this. Following error message is printed by the Java compiler when it comes to class Person:

Duplicate default methods named isDeleted with the parameters () and () are inherited from the types Named and Identified.

public class Person implements Identified, Named
{
    ....

    @Override
    public boolean isDeleted() {
        return Identified.super.isDeleted();
    }

}

The class decides for one of the defaults, in this case for the implementation in interface Identified.

Conclusion

Interface default implementations could easily take over the role that static utility classes have been playing until now (StringUtils, IOUtils, ...). Theses classes provided "pure" method implementations that rely on parameters only, without using their enclosing class body in any way. The problem with these utils is that they are not overridable. Interface default methods are overridable and would solve this problem. Method signature clashes would be found by the compiler.

Keep in mind that interfaces still can not hold any state, that means default implementations need to be "pure", everything they need has to be passed to them as parameter. But an interface now is the perfect place for "pure" functions.

Mind further that interfaces methods are always public, implicitly. You can not reduce their visibility to protected or private in an override.