equals and hashCode

Ben Evans benjamin.john.evans at gmail.com
Tue Oct 30 04:42:19 PDT 2012

On Tue, Oct 30, 2012 at 11:23 AM, Mark Thornton <mthornton at optrak.com> wrote:
> On 30/10/12 11:15, Aleksey Shipilev wrote:
>> That means lambdas inherit the default implementations of
>> equals/hashCode? It is as saying "you can't rely on equals()/hashCode()
>> for lambdas, since you are not in control of those". Although one can
>> piggyback on the factual behavior of lambdas, and we would have to
>> explicitly say when the lambdas are considered to be equal (or not). I.e.:
>>   Mapper lam1 = (x) -> x + 1;
>>   Mapper lam2 = (x) -> x + 1;
>> What are the expectations for equality? If we just inherit the default
>> equals/hashCode, I would expect:
>>   assertEquals(lam1, lam1);     // true
>>   assertEquals(lam1, lam2);     // false
> I think that in this case the implementation is permitted but not
> required to return true, i.e. lam1 == lam2 is possible but not guaranteed

This is a terrible idea.

Implementation-defined behaviour of something as fundamental as an
equality operation is going to help no-one.


More information about the lambda-dev mailing list