AbstractList etc. functionality as interfaces with default methods?

[Brian Goetz]

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.szegedi at 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.