The implementation of default methods

[Brian Goetz]

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.

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
>>