AbstractList etc. functionality as interfaces with default methods? (original) (raw)

Martin Buchholz martinrb at google.com
Thu May 14 01:02:59 UTC 2015

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

More information about the core-libs-dev mailing list