Chapter 9 of the book Java 8 in Action from Manning explains this in detail. Default methods are mainly for library designers. This is from the book:
Java 8 in Action wrote:...default methods were introduced to evolve libraries such as the Java API in a compatible way...
In a nutshell, adding a method to an interface is the source of many problems; existing classes implementing the interface need to be changed to provide an implementation for the method. If you're in control of the interface and all the implementations, then it's not too bad. But this is often not the case. This is the motivation for default methods: they let classes automatically inherit a default implementation from an interface.
...default methods provide a means to evolve interfaces without causing modifications to existing implementations.
So +1 to what Jeanne said: you should be careful in using this in your own code and should avoid using it in new code. When you use it for any purpose other than what it was intended to be, you're probably abusing or misusing it.
Suppose you have a Model/View/Controller application with a model that emits, say, ten different types of event. You also have more than one view running, but not all views will need to handle all events. If each distinct concrete view class implements the same view interface, each will have to implement methods that can handle, in total, all ten events, even though any given concrete view class might be interested in only two or three different types of event. In that case, each concrete view is going to have a number of implementations that look like this:
If you add new events with new methods declared for them in the interface, you are going to have to add something like the above to every existing concrete view, whether that view is interested in the event or not. If even one of your concrete views extends a superclass, you can't use an abstract class to get around the need to implement every method in the interface in every concrete view. Seems to me that a default implementation does a nice job of solving this problem.
Another approach I've seen (in "Head First Design Patterns," among other places) is to define a unique interface for each event type (or for each set of closely related events). Each concrete view then implements only the interfaces for the events it cares about. That can lead to a proliferation of interfaces and potential name-collisions between them.
Might this be a case where a single interface with default methods would be useful to someone writing new code, or is the multiple-interface approach the better choice (or something else)?
"Il y a peu de choses qui me soient impossibles..."