equals and hashCode

[Brian Goetz]

Yes, but not just equality; identity.  Which is the real problem -- we're still coping with the consequences of having naively decided 17 years ago that all non-primitive values must have identity.  (Work is going on in JVM-land to give us a better option.)

On Oct 30, 2012, at 8:03 AM, Aleksey Shipilev wrote:

> On 10/30/2012 03:42 PM, Ben Evans wrote:
>> 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.
> 
> I would be happy with "lambda equality is not defined" clause somewhere
> in the spec. The easiest way to implement this is to just let lambdas
> inherit Object.hashCode()/equals(). Sticking with some particular
> contract on lambda equality seems to counterfeit (possible) introduction
> of function types.
> 
> -Aleksey.
> 
>