equals and hashCode

[Brian Goetz]

Yes, it is decided: lambdas will inherit the implementation of 
equals/hashCode from Object.  So, that means no relief for the use case 
you are raising here.

(For more background, this topic has been discussed before on this list, 
in the context of listeners.  Ultimately you're fighting with 
computational physics; the problem is impossible in general (see Rice's 
theorem), all we can do is play whack-a-mole on a series of decreasingly 
"obvious" cases.  Each mole we whack just raises expectation that it 
will work for all cases, which ultimately is a fools errand.)

On 10/26/2012 3:11 PM, Robert J. Saulnier wrote:
> Any plans on having lambdas override equals and hashCode?
>
> I wanted to use a lambda as a key in a Map, but if you get the key
> from different classes, they are not equal.
>
> class A {
>
>      void m() {
>          Container.find(this::m); // <------ this::m should be equal to...
>      }
> }
>
> class B {
>
>      public static void main(String[] args) {
>          A a = new A();
>
>          Container.find(a::m); // <-------- ...a::m.
>      }
> }
>
> class Container {
>
>      public static Object find(Runnable r) {
>          //find something
>      }
> }
>
> Right now, the compiler will generate an inner class of A for this::m
> and an inner class of B for a::m. I think there might be use cases
> where these two inner classes are equal with matching hashCodes.
>
> - Bob
>