AbstractList etc. functionality as interfaces with default methods?

[Dan Smith]

> On May 14, 2015, at 7:24 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> On 05/14/2015 03:05 PM, Brian Goetz wrote:
>>>> Not only is there a problem with modCount, but also with equals/hashCode/toString.  You can’t define these Object methods in an interface.
>>> They could be defined as static methods to delegate to. From API consistency perspective, we have for example the following static methods on primitive wrapper classes:
>> Right.  We considered this during Lambda, but by the time we got here, we concluded that this was mostly trading one downside for another.  It seemed overwhelmingly likely that people would forget to override equals/hashCode/toString in this case, and create collections that violated the contract.
>> 
> 
> The other problem is that it creates ambiguous method references,
> if you have a class or an interface like:
> class A {
>  public static int hashCode(A a) { ... }
> }
> 
> A::hashCode is ambiguous.

An easy solution to both of these problems is to use a different name.  We discussed this as a workaround when designing the "no default 'hashCode' method" restriction.

interface List<E> {
    ...

    /** Returns the hash code for this list.  The hash code of a list is defined as ... */
    int hashCode();

    /** Computes a hash code consistent with the specification of 'hashCode'. */
    default int defaultHashCode() { ... }
}

(Details like whether it's static or instance, and what interface it lives in, are flexible.)

—Dan