AbstractList etc. functionality as interfaces with default methods?

Peter Levart peter.levart at gmail.com
Thu May 14 13:51:22 UTC 2015

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

More information about the core-libs-dev mailing list