lambda and MethodHandles in current prototype

[Brian Goetz]

That is correct.  The spec makes *NO* promises about the identity of 
boxed lambda expressions, and the runtime has latitude to fold together 
equivalent lambdas, or not, as it sees fit.  Equality comparisons on 
lambda expressions are not meaningful (beyond the inherent reflexivity 
of equality).  This is to maximize flexible for the VM and language 
runtime to represent the function most efficiently.

That said, you can still use them as keys in a map.  What you can't do 
is reliably identify that two functions are necessarily the same 
function.  (In the general case, this is undecidable anyway; see 
http://en.wikipedia.org/wiki/Rice's_theorem.)

In your example, sum1 and sum1a are guaranteed to be equal.  None of the 
other cases are guaranteed (though it is likely under most "reasonable" 
implementations that sum2 == sum2a, and that sum1 != sum1b.)

Note also that it is almost certainly the case that the following will 
print false:

void moo(int target) {
     Foo[] foos = new Foo[2];
     for (int i=0; i<2; i++)
         foos[i] = x -> x == target;
     System.out.println(foos[0] == foos[1]);
}

Even though they the function they compute is derived from the same 
code, they are different because they are the result of partially 
applying the captured variable 'target'.




On 11/20/2011 3:11 PM, Yuval Shavit wrote:
> Does that mean that in the example above, sum1 == sum2 and
> sum1.equals(sum2) are both undefined? If so, what about:
>
>     IntOperator sum1 = (a, b) -> a + b;
>     IntOperator sum1a = sum1;
>     IntOperator sum1b = (a, b) -> a + b;
>
> Similarly,
>
>     IntOperator sum2 = Test#sum
>     IntOperator sum2a = Test#sum
>
>
> Presumably sum1 = sum1a, and sum1.equals(sum1a). Is there any definition
> of equality between sum1 and sub1b? What about sum2 and sum2a?
>
> I would think it'd be helpful to define these equalities, in case
> someone wants to use the references in a set, map, etc.
>
> On Sun, Nov 20, 2011 at 2:35 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Ignore everything having to do with the compilation strategy (and any
>     consequent performance considerations) for the time being.  It is
>     completely temporary, just enough to make things work while the language
>     runtime is catching up with the compiler.
>
>     The final specification will allow great latitude to the language
>     runtime to construct the instance however it wants: dynamically spun
>     inner classes, wrapper classes around method handles, dynamic proxies,
>     method handle proxies, or other as yet unknown mechanisms.  And to
>     change it as often as it feels like.  So the behavior of your test
>     program will be completely implementation-dependent, and could even
>     change from run to run.
>
>     You seem to be imploying that it is beneficial to specify the behavior
>     more tightly.  Why is this good?  Is is simply that you want to know
>     whether an object is the result of a lambda expression (and if so, what
>     would you do with this information?), or something more?
>
>     On 11/20/2011 1:58 PM, Peter Levart wrote:
>      > I tried the prototype in binary distribution and was surprised
>     that the following code:
>      >
>      > import java.lang.invoke.MethodHandleProxies;
>      > import java.util.functions.IntOperator;
>      >
>      > public class Test
>      > {
>      >     static int sum(int a, int b)
>      >     {
>      >        return a + b;
>      >     }
>      >
>      >     public static void main(String[] args)
>      >     {
>      >        IntOperator sum1 = (a, b) ->  a + b;
>      >        IntOperator sum2 = Test#sum;
>      >
>      >
>       System.out.println(MethodHandleProxies.isWrapperInstance(sum1));
>      >
>       System.out.println(MethodHandleProxies.isWrapperInstance(sum2));
>      >     }
>      > }
>      >
>      >
>      > prints:
>      >
>      > false
>      > false
>      >
>      >
>      > Has the compilation strategy changed? Aren't MethodHandles used
>     any more or are they still, but the conversion to functional
>     interfaces doesn't use MethodHandleProxies.asInterfaceInstance()?
>     Are there any plans for the above code to print true/true (or at
>     least false/true)?
>      >
>      > Regards,
>      >
>      > Peter
>      >
>
>