AbstractList etc. functionality as interfaces with default methods?

[Ivan Gerasimov]

I was just going to propose something similar: A base abstract class for 
AbstractList, which implements everything but SubList-related stuff 
(including modCount).
This way we could easily create specializations for sublists of 
Arrays.ArrayList and Collections.SingleToneList, which do not need to 
track structural modifications.
Please see the sibling thread 'RFR: 8079136: Accessing a nested sublist 
leads to StackOverflowError'.

This new base class shouldn't be a part of public API, of course.

Sincerely yours,
Ivan

On 08.05.2015 12:41, Attila Szegedi 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.
>