In The new Java 8 Date and Time API: An interview with Stephen Colebourne, Stephen Colebourne tells Hartmut Schlosser, “I think the most important language change isn’t lambdas, but static and default methods on interfaces.” Colebourne adds, “The addition of default methods removes many of the reasons to use abstract classes.” As I read this, I realized that Colebourne is correct and that many situations in which I currently use abstract classes could be replaced with interfaces with JDK 8 default methods. This is pretty significant in the Java world as the difference between abstract classes and interfaces has been one of the issues that vex new Java developers trying to understand the difference. In many ways, differentiating between the two is even more difficult in JDK 8.
There are numerous examples of online forums and blogs discussing the differences between interfaces and abstract classes in Java. These include, but are not limited to, JavaWorld‘s Abstract classes vs. interfaces, StackOverflow‘s When do I have to use interfaces instead of abstract classes?, Difference Between Interface and Abstract Class, 10 Abstract Class and Interface Interview Questions Answers in Java, As useful and informative as these once were, many of them are now outdated and may be part of even more confusion for those new to Java who start their Java experience with JDK 8.
As I was thinking about the remaining differences between Java interfaces and abstract classes in a JDK 8 world, I decided to see what the Java Tutorial had to say on this. The tutorial has been updated to reflect JDK 8 and the Abstract Methods and Classes has a section called “Abstract Classes Compared to Interfaces” that has been updated to incorporate JDK 8. This section points out the similarities and differences of JDK 8 interfaces with abstract classes. The differences it highlights are the accessibility of data members and methods: abstract classes allow non-static and non-final fields and allow methods to be public, private, or protected while interfaces’ fields are inherently public, static, and final, and all interface methods are inherently public.
The Java Tutorial goes on to list bullets for when an abstract class should be considered and for when an interface should be considered. Unsurprisingly, these are derived from the previously mentioned differences and have primarily to do with whether you need fields and methods to be private, protected, non-static, or not final (favor abstract class) or whether you need the ability to focus on typing without regard to implementation (favor interface).
Because Java allows a class to implement multiple interfaces but extend only one class, the interface might be considered advantageous when a particular implementation needs to be associated with multiple types. Thanks to the JDK 8’s default methods, these interfaces can even provide default behavior for implementations.
A natural question might be, “How does Java handle a class that implements two interfaces, both of which describe a default method with the same signature?” The answer is that this is a compilation error. This is shown in the next screen snapshot which shows NetBeans 8 reporting the error when my class implemented two interfaces that each defined a default method with the same signature [String speak()].
As the screen snapshot above indicates, a compiler error is shown that states, “class … inherits unrelated defaults for … from types … and …” (where the class name, defaults method name, and two interface names are whatever are specified in the message). Peter Verhas has written a detailed post (“Java 8 default methods: what can and can not do?“) looking at some corner cases (gotchas) related to multiply implemented interfaces with default method names with the same signature.
Conclusion
JDK 8 brings arguably the abstract class’s greatest advantage over the interface to the interface. The implication of this is that a large number of abstract classes used today can likely be replaced by interfaces with default methods and a large number of future constructs that would have been abstract classes will now instead be interfaces with default methods.
| Reference: | Abstract Class Versus Interface in the JDK 8 Era from our JCG partner Dustin Marx at the Inspired by Actual Events blog. |
In essence you are suggesting java has moved towards multiple inheritance. The new interface gives best of both interface and abstract classes and allowing multiple interface with default behavior. Kind of looks lame to me why didn’t they think of this at the first place earlier, actually what they should do is force a default behavior to all interface methods that way one need not think of implementing one if he doesn’t have to. What I am suggesting is the default behavior can be more or less a blue print for someone to come up with a different implementation. I… Read more »
I would advise against this to be honest. Multiple inheritance might exist but that doesn’t mean that it is a good thing. Interfaces are meant to be safe to inherit from regardless of what other interfaces you inherit from. The biggest danger here is that the interface becomes a place for “utility” methods. These methods are sometimes useful but more often than not should be done through delegation rather than inheritance. Inheritance itself is the tightest form of coupling. Putting the word optional on it just muddies the waters. The other thing thing is that a default method cannot rely… Read more »
I agree with kevin Timmins. Adding default methods in interfaces will bring a lot of methods as utility methods and thus it will create a confusion to developers. some default methods will be implemented and some methods not …. :)
I love programmering ，but I also love java
Greetings….!!!, Plz Help me to understand Java API’s.