On Nov 30, 2012, at 7:56 AM, Remi Forax wrote: > On 11/30/2012 01:50 PM, Lance Andersen - Oracle 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. > > @implementation ? > >> >> 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 > > an UnsupportedOperationException is better for that.
Agree that could be a better choice > >> or a SQLFeatureNotSupportedException for methods which may be optional based >> on the backend support. > > Rémi >
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
