Default method survey results

[Yuval Shavit]

On Fri, Aug 17, 2012 at 1:27 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> On Thu, Aug 16, 2012 at 12:32 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >> The oddity of "default" implementation is that it puts the programmer
> >> in a box. He has to provide some sort of implementation that does not
> >> rely on state. That's an odd place to be in -- especially if no
> >> suitable implementation can be given without state.
> >
> > No, there are plenty of default methods that can be implemented without
> > access to state.  For example, there are optional methods.  For example,
> > Iterator.remove() can have a default to throw UOE, so that the 99% of
> > Iterator implementations that don't want to implement remove() don't
> > have to implement a version that throws.
>
> That means it was a mistake to include remove() in Iterator. And now
> we use a tool to mask that mistake, ending up with 2 mistakes. There
> should not be a default impl of Iterator.remove() - a default impl
> must work in all cases, not just in common cases.


Well, throwing UOE from Iterator.remove() *does* work in all cases, in that
it always conforms to the Iterator contract (which states that you may
throw UOE from remove()). If you want more interesting behavior, you are
free to provide it.

That said, it's not clear to me that that's the right behavior. I would
rather have an abstract UnmodifiableIterator which fills in that method. At
that point, I think there are a few options:

   - UI is an interface with a default method; its contract is unchanged
from Iterator's, and it's purely a convenience for implementers
   - UI is an abstract class, and remove() is final; its contract
strengthens Iterator's to say that remove() *must* throw UOE
   - UI is an interface with a default method which also strengthens the
contract; overriding the default method to provide a non-UOE implementation
is a bug, but one the compiler can't catch
   - UI is an interface with a final default method which stengthens the
contract; maybe in Java 9+ ?