hg: lambda/lambda/langtools: 8010010: NPE generating serializedLambdaName for nested lambda

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Mar 21 04:56:22 PDT 2013


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