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.
