Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
ricky.clarkson at gmail.com
Fri Nov 30 13:14:46 UTC 2012
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
> >>>> 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
> >>>> 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
More information about the core-libs-dev