equals and hashCode

[Ben Evans]

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.

Ben