The implementation of default methods (original) (raw)

Brian Goetz brian.goetz at oracle.com
Sat Dec 15 07:56:38 PST 2012

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

More information about the lambda-libs-spec-experts mailing list