AbstractList etc. functionality as interfaces with default methods?

Attila Szegedi attila.szegedi at oracle.com
Fri May 8 15:25:42 UTC 2015


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