hg: lambda/lambda/langtools: 8010010: NPE generating serializedLambdaName for nested lambda
Robert Field
robert.field at oracle.com
Thu Mar 21 09:30:08 PDT 2013
On 03/21/13 05:43, Maurizio Cimadamore wrote:
> Fixed.
Oops!
Thanks Maurizio!
-Robert
>
> Maurizio
>
> On 21/03/13 11:56, Maurizio Cimadamore wrote:
>> On 20/03/13 19:05, robert.field at oracle.com wrote:
>>> Changeset: 85ba5a25c9e2
>>> Author: rfield
>>> Date: 2013-03-20 12:05 -0700
>>> URL:
>>> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/85ba5a25c9e2
>>>
>>> 8010010: NPE generating serializedLambdaName for nested lambda
>>> Reviewed-by: mcimadamore
>>>
>>> ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
>>>
>>>
>> This causes several regression failures and crashes. I believe you
>> didn't see those because you are running tests with assertion disabled.
>>
>> One thing that I missed during the review is that for throwing assertion
>> you should use the utility method
>>
>> Assert.check(condition)
>>
>> instead of the language
>>
>> assert condition
>>
>> The former will throw an assertion error regardless of assertions being
>> enabled at the VM level - so you will catch'em'all.
>>
>> The problem with the patch is, I think that the assertion is wrong:
>>
>> if (owner.type != null) {
>> Assert.check(directlyEnclosingLambda() != null);
>>
>> If a lambda is nested into another lambda, the owner will be null. Which
>> should mean that if the owner is not null, it should be a toplevel
>> lambda, so directlyEnclosingLambda should be null.
>>
>> Since I have to take another stab at the code, I think I will rewrite
>> the code:
>>
>> Assert.check(owner.type != null || directlyEnclosingLambda() != null);
>> if (owner.type != null) {
>> ...
>> }
>>
>> In fact, the existing assertion doesn't trigger if a null owner is found
>> when not in a nested lambda, which was the whole point of the exercise.
>>
>> Maurizio
>>
>
More information about the lambda-dev
mailing list