AbstractList etc. functionality as interfaces with default methods?

[Martin Buchholz]

I'm also in the business of maintaining List implementations and would like
to share implementation code.  Unfortunately, Java does not provide much
help.  Java confuses inheritance and subtyping. Public abstract
superclasses leak through (users might mistakenly use AbstractList in their
API) and of course we only have single inheritance.  Default methods are
not Traits, much as we would like them to be - they were explicitly
designed to enable interface evolution. They are leaky in the same way as
abstract classes.  Will Jigsaw help?  I'm not sure, but I'm pessimistic.

On Fri, May 8, 2015 at 8:25 AM, Attila Szegedi <attila.szegedi at oracle.com>
wrote:

> Well then those would obviously be left out, documenting that it’s the
> responsibility of the implementor to provide them. This would be true in
> general for other interfaces as well that have a specification for expected
> meaning of equals/hashCode.
>
> There’s still a lot of boilerplate code that could be saved from
> repetition, though.
>
> > On May 8, 2015, at 12:15 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> >
> >
> >> (I’ll hand-wave the issue of “protected int modCount” issue for now.)
> >
> > Not only. Consider this: java.util.AbstractList overrides some methods
> from
> > java.lang.Object such as equals and hashCode. And this is a no-no [1]:
> >
> >    ...It is a compile-time error if a default method is
> override-equivalent
> >    with a non-private method of the class Object, because any class
> >    implementing the interface will inherit its own implementation of the
> >    method...
> >
> >
> -------------------------------------------------------------------------------
> > [1]
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.4.1.2
>
>