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

[Lance Andersen - Oracle]

The problem for an API such as JDBC is that the implementation is going to be specific to the driver and backend so providing a default implementation just won't work.  This allows existing drivers to compile as they finish their implementation and complete their migration to the new version of the API.  


On Nov 30, 2012, at 8:14 AM, Ricky Clarkson wrote:

> What is the benefit of throwing an IllegalStateException in a default method over not providing any default method so that the compiler and runtime make sure concrete subtypes provide an implementation?
> 
> On Nov 30, 2012 9:54 AM, "Lance Andersen - Oracle" <Lance.Andersen at oracle.com> wrote:
> 
> On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote:
> 
> >
> >
> > On 30/11/2012 02:03, David Holmes wrote:
> >> 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.
> >
> > Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation.
> 
> I had wondered about this as well and had a brief email exchange with Mike.  I thought a new javadoc tag might also be something to consider.
> 
> For  JDBC,  I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support.
> >
> > -Chris.
> >
> >>
> >> But maybe we kid ourselves when we give this illusion of flexibility in
> >> implementation.
> >>
> >> David
> >>
> >>> -Chris.
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 
> 
> 
> 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com