@Override and default methods

[Brian Goetz]

>> 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 
than projected.

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 
looong time.)