recursive lambda as a local variable

[Remi Forax]

On 09/13/2013 02:45 PM, Peter Levart wrote:
> On 09/13/2013 12:51 PM, Remi Forax wrote:
>> On 09/13/2013 10:21 AM, Peter Levart wrote:
>>> On 09/12/2013 05:17 PM, Brian Goetz wrote:
>>>>> - The part left of the '::' can be an arbitrarily long expression 
>>>>> that will
>>>>> be evaluated immediately, while the method invocation itself will be
>>>>> deferred until the corresponding SAM method is invoked. Thus, 
>>>>> 'null' might
>>>>> by bound now and detected much later.
>>>> This is just a compiler bug; if the part to the left evaluates to 
>>>> null,
>>>> it should throw NPE immediately (see jsr335-15.28.2-30-A2: If the 
>>>> result
>>>> of evaluation of the subexpression is null, then a 
>>>> NullPointerException
>>>> is thrown.)
>>>>
>>>> Thanks for reporting this.  I will file a bug.
>>> This could be checked in lambda metafactory generated constructor,
>>> right? It doesn't have to be compiler generated code.
>>>
>>> Regards, Peter
>> yes,
>> but it requires to change the protocol between javac and the lambda
>> metafactory
>> to signal if a captured parameter is bound or not.
>
> Does it? The "MethodHandle implMethod" meta factory argument is a 
> target method to be called. With MethodHandleInfo API, the metafactory 
> can find out whether it's a static method or not. if it's an instance 
> method and the receiver is passed-in at capture time (as opposed to be 
> passed-in at call time), then it must be a bound receiver. Is there a 
> case where the target method is an instance method and the bound 
> receiver should be allowed to be null at capture time?

It seems to work, but I think there is still an issue if we move from 
the current implementation that generate one class by lambda
to an implementation that generate one class for all lambda that 
implement the same functional interface. In that case,
we need to curry the method handle corresponding to the lambada and the 
captured values and having a null check in
the middle is not something cool because it adds a method handle adapter 
in between.

>
> Regards, Peter

cheers,
Rémi

>
>>
>> It seems simpler, to me, to modify javac to generate
>>     DUP
>>     INVOKEVIRTUAL Object.getClass()
>> in front of the first argument of the invokedynamic call.
>>
>> Rémi
>>
>>
>