Java 8 allows for default implementation of methods in interfaces called Default Methods.
I am confused between when would I use that sort of interface default
There are a few technical differences. Abstract classes can still do more in comparison to Java 8 interfaces:
Conceptually, main purpose of defender methods is a backward compatibility after introduction of new features (as lambda-functions) in Java 8.
Remi Forax rule is You don't design with Abstract classes. You design your app with interfaces. Watever is the version of Java, whatever is the language. It is backed by the Interface segregation principle in SOLID principles.
You can later use Abstract classes to factorize code. Now with Java 8 you can do it directly in the interface. This is a facility, not more.
Whenever we have a choice between abstract class and interface we should always (almost) prefer default (also known as defender or virtual extensions) methods.
Default methods have put an end to classic pattern of interface and a companion class that implements most or all of the methods in that interface. An example is Collection and AbstractCollection
. Now we should implement the methods in the interface itself to provide default functionality. The classes which implement the interface has choice to override the methods or inherit the default implementation.
Another important use of default methods is interface evolution
. Suppose I had a class Ball as:
public class Ball implements Collection { ... }
Now in Java 8 a new feature streams in introduced. We can get a stream by using stream
method added to the interface. If stream
were not a default method all the implementations for Collection
interface would have broken as they would not be implementing this new method. Adding a non-default method to an interface is not source-compatible
.
But suppose we do not recompile the class and use an old jar file which contains this class Ball
. The class will load fine without this missing method, instances can be created and it seems everything is working fine. BUT if program invokes stream
method on instance of Ball
we will get AbstractMethodError
. So making method default solved both the problems.
Java 9 has got even private methods in interface which can be used to encapsulate the common code logic that was used in the interface methods that provided a default implementation.
This is being described in this article. Think about forEach
of Collections.
List<?> list = …
list.forEach(…);
The forEach isn’t declared by
java.util.List
nor thejava.util.Collection
interface yet. One obvious solution would be to just add the new method to the existing interface and provide the implementation where required in the JDK. However, once published, it is impossible to add methods to an interface without breaking the existing implementation.The benefit that default methods bring is that now it’s possible to add a new default method to the interface and it doesn’t break the implementations.
As mentioned in other answers, the ability to add implementation to an interface was added in order to provide backward compatibility in the Collections framework. I would argue that providing backward compatibility is potentially the only good reason for adding implementation to an interface.
Otherwise, if you add implementation to an interface, you are breaking the fundamental law for why interfaces were added in the first place. Java is a single inheritance language, unlike C++ which allows for multiple inheritance. Interfaces provide the typing benefits that come with a language that supports multiple inheritance without introducing the problems that come with multiple inheritance.
More specifically, Java only allows single inheritance of an implementation, but it does allow multiple inheritance of interfaces. For example, the following is valid Java code:
class MyObject extends String implements Runnable, Comparable { ... }
MyObject
inherits only one implementation, but it inherits three contracts.
Java passed on multiple inheritance of implementation because multiple inheritance of implementation comes with a host of thorny problems, which are outside the scope of this answer. Interfaces were added to allow multiple inheritance of contracts (aka interfaces) without the problems of multiple inheritance of implementation.
To support my point, here is a quote from Ken Arnold and James Gosling from the book The Java Programming Language, 4th edition:
Single inheritance precludes some useful and correct designs. The problems of multiple inheritance arise from multiple inheritance of implementation, but in many cases multiple inheritance is used to inherit a number of abstract contracts and perhaps one concrete implementation. Providing a means to inherit an abstract contract without inheriting an implementation allows the typing benefits of multiple inheritance without the problems of multiple implementation inheritance. The inheritance of an abstract contract is termed interface inheritance. The Java programming language supports interface inheritance by allowing you to declare an
interface
type
Default methods in Java interface enables interface evolution.
Given an existing interface, if you wish to add a method to it without breaking the binary compatibility with older versions of the interface, you have two options at hands: add a default or a static method. Indeed, any abstract method added to the interface would have to be impleted by the classes or interfaces implementing this interface.
A static method is unique to a class. A default method is unique to an instance of the class.
If you add a default method to an existing interface, classes and interfaces which implement this interface do not need to implement it. They can
More on the topic here.