• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown
Bartenders:

java 8 interface default

 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
can someone explain why java 8 starteed allowing "default" implementation of a method in an interface.
I thought that was the whole point of seperating Interfaces and Abstract classes.

I like it but what happened to convince people that change would be a good thing???
 
author & internet detective
Posts: 41502
881
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's controversial. As far as I can tell, the main reason they did it was so they could add functional programming APIs to the Collections interfaces.

I think it is one of those features you should use sparingly in your own code. And never/almost never on new code.
 
Sheriff
Posts: 17405
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 77157
370
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I shall copy this discussion in the Java8 forum.
 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)?
 
reply
    Bookmark Topic Watch Topic
  • New Topic