Not only is there a problem with modCount, but also with
equals/hashCode/toString. You can’t define these Object methods in an
interface.
On May 8, 2015, at 5:41 AM, Attila Szegedi <attila.szeg...@oracle.com> wrote:
> So I’m in a position where I’d need to have a class implement List, but it
> already extends something else, so I can’t have it extend AbstractList, which
> leaves me with a lot of boilerplate methods to implement.
>
> Would it seem like a good idea to reimagine AbstractList and friends as
> interfaces with default methods?
>
> Of course, I know that technically for backwards compatibility we can’t
> really do this, but what we could do is:
>
> public interface DefaultList<T> extends List<T> {
> … add all methods from AbstractList here as default methods …
> }
>
> public abstract class AbstractList<T> implements DefaultList<T> {
> }
>
> (I’ll hand-wave the issue of “protected int modCount” issue for now.)
>
> Actually, this seems like such an obvious idea that I’m 100% sure it must’ve
> been considered before, but I can’t find any related discussion.
>
> Attila.
