equals and hashCode

[Remi Forax]

On 10/30/2012 12: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.

Like Ben, I think it's a bad idea to have a sloppy definition of the 
equality,
boxing rules in the current spec are like this and users and VM implementers
find this awful, they is no requirement to make the same mistake twice :)

Moreover, here, to return true, the VM and the compiler will have to 
work together,
and no one want something like sharing will work only if you compile 
with eclipse and use J9
or with javac and use Hotspot.

>
> Ben
>

Rémi