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

[Ricky Clarkson]

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
>
>
>
>
>