@Override and default methods
brian.goetz at oracle.com
Sun Nov 17 04:04:56 PST 2013
>> My concern is how intrusive default methods can be. If someone adds a
>> default method to a super interface and it conflicts with existing methods
>> in a sub-interface, you can't compile. This pattern is ought to repeat over
>> and over. JDK 9 or 10 or the future may continue to add new default methods
>> and break sub-interfaces.
> This was deemed an acceptable price to pay to allow the platform classes
> to move forward. Some code will need modification to run on Java 8.
Yes; the EG discussed this risk extensively (i.e., this is not a
surprise to us) and further explored and ultimately rejected a number of
mitigation strategies. We will continue to consider the option of
mitigation strategies going forward should things turn out to be worse
These particular method signatures were taken from ConcurrentMap, so
that the methods from ConcurrentMap could (finally) be brought down to
all Maps. (Had default methods been around in 5, we would have likely
added them to Map at that time, but ConcurrentMap was the best we could
do at the time.) So the API design work for these particular
conflicting methods was done ten years ago.
Your gloom-and-doom "it will happen all the time, and it will be CHAOS!"
prediction is overblown; that assumes zero restraint on the part of JDK
maintainers. (If anything, the more common complaint against us is
usually "too much restraint". But it might result in more disruption
for users of third-party libraries, should their maintainers go
overboard.) But you are correct to observe that widely-implemented
interfaces such as Iterator, Iterable, Collection, List, Map, etc,
should be evolved minimally and carefully, as the more widely
implemented a type is, the more likely a conflict with subclass methods
will be. (Note that this is by no means a problem that is new with
default methods; we have had this problem with classes since day 1.)
Note also that this was one of the reasons we ultimately didn't put all
the map/filter/reduce methods directly on Collection; this would have
greatly increased the chance of collision, adding dozens of methods
instead of a few.
(In this particular case, we might also have had more options had we
heard from Apache earlier. Binary builds have been available for a
More information about the lambda-dev