Problem with lambda expression in initialization block

[Remi Forax]

On 09/16/2012 04:51 PM, Brian Goetz wrote:
>> So AbstractValidatingLambdaMetafactory.validateMetafactoryArgs should be
>> changed to allow
>> lambda that are constructed with a super call.
>
> No, if your theory is correct (and we've seen this bug elsewhere), its 
> a VM bug introduced in the new 292 implementation.
>
> We use the MethodHandle-cracking API DanH spoke about at JVMLS. If 
> MethodHandleInfo reports that a MH is of kind REF_special, then it had 
> better be invokable with invokespecial.  If the check in AVLMF were to 
> pass this through (we tried it), the invoke would fail.
>
> Its a straight bug in the new MethodHandleInfo.

No, if there is a bug, it's because the invoke had fail.

If you have something like,
class A {
   private void foo() {
      ...
   }

   private void bar() {
      foo();    // here the compiler is free to use invokespecial 
instead of invokevirtual
   }
}

What's happen with MethodHandleInfo is exactly the same, the VM knows 
that because
the class is final, the lambda method generated by javac can not be 
overriden.
So even if you create your method handle with a findVirtual, the VM is 
free to encode it
as if it was a findSpecial and the MethdoHandleInfo API is an API that 
crack method handle
not an API that reflects the way a method handle is created, otherwise 
the VM will have to
store metadata in the method handle only because it can be cracked 
making method handle
less lightweight. Because dynamic langages can create one hundred 
thousand method handles
(think big rail application), each method handle has to be as 
lightweight as possible.

cheers,
Rémi