recursive lambda as a local variable

[Vicente-Arturo Romero-Zaldivar]

On 13/09/13 14:39, Remi Forax wrote:
> 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
>>>
>>>
>
Hi all,

This changeset: 
http://hg.openjdk.java.net/jdk8/tl/langtools/rev/571f8ebc2d51, already 
in TL, fixes this issue.

Thanks for the report.

Vicente