lambda and MethodHandles in current prototype

[Brian Goetz]

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
>