AbstractList etc. functionality as interfaces with default methods?

[Peter Levart]

On 05/14/2015 03:24 PM, Remi Forax 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.

That's a good reason.

>>
>
> 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.

Ah, I see. Then Integer::hashCode is ambiguous too if the target 
functional interface takes boxed Integer parameter.

Regards, Peter

>
> cheers,
> Rémi
>