The implementation of default methods

[David Holmes]

On 16/12/2012 1:56 AM, Brian Goetz wrote:
> For Iterator.remove, I think the real constraint is: the JDK must
> provide *a* default implementation (since this is only an issue for
> compatibility across JDKs). Since the only reasonable default would be
> to throw something, we might as well specify what is thrown, since this
> degree of freedom serves noone: the JDK must provide a default that
> throws UOE.

One example does not a policy make. We have to address the general issue 
not, I hope, do a case-by-case analysis to see if we think any other 
default implementation is possible or reasonable. Put another way do we say:

"This default implementation does ..."

or

"The default implementation does ..."

?


On a related but separate note, the "is equivalent to" approach has 
caused not insignificant confusion over the years because no one knows 
exactly what it means and then we get bug reports because it's only 
equivalent in the base class, not in any subclasses (eg we call a 
private method that 'is equivalent to' calling a bunch of public methods 
but we don't actually call them so overriding in the subclass doesn't 
have the expected affect).

David
-----


> On 12/15/2012 1:50 AM, David Holmes wrote:
>> On 15/12/2012 2:45 AM, Doug Lea wrote:
>>> On 12/14/12 11:30, Brian Goetz wrote:
>>>
>>>> 1. Document "Implementation note: The default implementation
>>>> currently..."
>>>
>>> As always, the fewer of these the better. In j.u/j.u.c, these
>>> are used mostly for resource limitations (like max threads in FJP)
>>> that might someday be lifted.
>>>
>>>>
>>>> 2. Document "The default implementation behaves as if..." (Or whatever
>>>> Doug's
>>>> proposed wording is.)
>>>
>>> In j.u.c, we always say "is behaviorally equivalent to" but I dropped
>>> the "behaviorally" in Map candidate because someone once told me
>>> it was overly pedantic :-)
>>>
>>>>
>>>> 3. Document "The default implementation MUST"
>>>
>>> Isn't this just the normal spec part, that should precede the default
>>> implementation part?
>>
>> I think not. The "normal spec" describes the abstract operation. "The
>> default implementation MUST" specifies the concrete implementation.
>>
>> But it sounds like we do not intend to lock in what these default
>> implementations do, so, for example, my version of j.u.Iterator.remove
>> doesn't have to throw UnsupportedOperationException if I have some magic
>> way of providing a default remove operation - correct?
>>
>> David
>>
>>> -Doug
>>>