Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces

David Holmes david.holmes at
Fri Nov 30 02:03:34 UTC 2012

On 30/11/2012 12:44 AM, Chris Hegarty wrote:
> On 11/29/2012 05:50 AM, David Holmes wrote:
>> ...
>> I don't agree that we need to describe what the default implementation
>> does, for two reasons:
>> 1. Normal methods don't usually specify how they are implemented - it is
>> an implementation detail. The "default" simply indicates that this
>> method does have an implementation and you should expect that
>> implementation to obey the contract of the method.
>> 2. It is not obvious to me that the JDK's choice for a default
>> implementation has to be _the_ only possible implementation choice. In
>> many/most cases there will be a very obvious choice, but that doesn't
>> mean that all suppliers of OpenJDK classes have to be locked in to that
>> choice.
> This is certainly interesting, and something I've wondered for a while
> now. If java.util.Iterator is to ever be fitted with a default
> implementation of remove ( to throw UnsupportedOperationException ),
> then it would clearly need to be part of the spec, and not an
> implementation detail of OpenJDK. Otherwise, what's the point, every
> developer will still have to implement it because they cannot be
> guaranteed of it's behavior.

I think optional methods are a bit of a special case here because they 
don't have to work.

It's the end user of a class that needs to understand if they can use 
remove() to actually do a removal. The developer of the class can 
inherit whatever default implementations Iterator provides, as long as 
they don't mind what they get. If they do mind ie they need a real 
remove(), then they will have to implement it themselves and in the 
process document that fact. The end user has to look at the docs for the 
concrete class and follow through to determine whether it's 
iterator().remove() is optional or not.

Put another way, a default method is great for adding a new method to 
types that have not yet been revised to handle the new method. As a 
developer once you revise your class you should make a conscious 
implementation choice in my opinion and not rely on the default unless 
you truly don't care what it does.

But maybe we kid ourselves when we give this illusion of flexibility in 


> -Chris.

More information about the core-libs-dev mailing list