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
