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.ander...@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.ander...@oracle.com > > > > >
