Why is adding default methods to interfaces in Java 8 a good design choice and what are the alternatives [duplicate]

Question

I am just learning Java, so it is hard for me to access the possible alternatives, and the impact of such a design decision.

Java 8 adds the default methods feature to interfaces, which allows interfaces to have an implementation. This allows to extend the existing interfaces with new methods, without breaking the clients, evolving the interface over time in a backward-compatible way. However, given default implementation, such extensions are somewhat limited, and are likely to be implemented using existing interface methods of the interface or library methods. So my question is

• Why was this language feature introduced?
• What key new features does it support? (for instance Splititerators)
• What other alternatives were there to support those language features? For example, why not create a new interface SplitIterable that extends Iterable?
• What would be the impact of implementing those alternatives (poliferation of interfaces?)
• Should I provide a default implementation for a method in the first edition of interface when it is possible to implement it as a composition of other methods?

Answer 1

Why was this language feature introduced?

It was added primarily to let you add methods to existing interfaces that are already in use without breaking everyone's code, but also to share method implementations "horizontally" across classes implementing the same interface (as opposed to "vertical" sharing through inheritance).

What key new features does it support? (for instance Splititerators)

java.util.Collection<T>.stream()

What other alternatives were there to support those language features? For example, why not create a new interface SplitIterable that extends Iterable?

You could opt for entirely new interfaces, and continue with the associated static helper class (e.g. Collection<T> interface and its Collections helper class). This wouldn't be terrible - in fact, one could argue that default methods are purely a syntactic sugar on top of static methods^*. However, default methods generally provide for better readability.

What would be the impact of implementing those alternatives (proliferation of interfaces?)

You would end up with a less consistent library, and a less readable language, but it wouldn't be the end of the world. A bigger concern, as pointed out by Joachim Sauer, is that interface implementations would have no way to override implementation from the static helper class. That would take away flexibility.

Should I provide a default implementation for a method in the first edition of interface when it is possible to implement it as a composition of other methods?

You should do it only if you need to share implementation "horizontally". If a method provides essential behavior of the implementation, do not provide a default for it.

^* This would be an oversimplification, because default methods remain virtual. Thanks Brian Goetz for the comment.