AbstractList etc. functionality as interfaces with default methods?

Vitaly Davidovich vitalyd at gmail.com
Thu May 14 13:52:38 UTC 2015

Ambiguous in isolation, but within context they're quite different: one
takes an arg and the other is void.

sent from my phone
On May 14, 2015 9:25 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.
> cheers,
> Rémi

More information about the core-libs-dev mailing list