SAM identity or at least equals/hashCode

[Brian Goetz]

> This is exactly the use case I'm talking about. One would want that
>
> constGenerator(12).equals(constGenerator(12)) would evaluate to true and
> constGenerator(12).equals(constGenerator(13)) would evaluate to false

I could understand one would want that, but its not worth what it costs.

>> Clients will call the resulting IntFactory with
>>     foo.make()
>> and expect an int to come back.  The SAM-converted lambda is an object,
>> it has to have a nilary make() method, that method has captured state x,
>> so where do we store the captured state?
>>
>
> I belive you (could) generate a static method with one formal parameter:
>
> private static int lambda$1(Integer p1) { return p1; }

Which is exactly what the compiler does.

> ...then obtain a MethodHandle for it, say: lambda$1Mh
> ...then capture the final x: lambda$1BoundMh = lambda$1Mh.bindTo(x);

Which is one, but not the only, mechanism for SAM-conversion under 
consideration.

> Now, I don't know much about MHs and how they are implemented and optimized in the VM, so perhaps such scheme would defeat those optimizations. Or is it still possible?

Method handles are a low-level VM technique for representing *methods* 
in a lightweight way.  Adding in all the Object crap would undermine 
that lightness.

Bottom line: trying to support .equals() on lambdas spectacularly fails 
the cost benefit analysis.  The benefit is almost nil; the cost is 
significant.