javac crash for annotation on lambda formal parameter type

Werner Dietl wdietl at
Thu Dec 5 17:51:58 PST 2013

It looks like nobody ever tested Type Annotations on Lambdas in fields.
contain several lambda tests, but all within methods.

The code that creates the NPE tries to find the owner for a parameter symbol.
The expectation was that a parameter is always within an method. That
is not true for lambdas it seems.
Even for lambdas within a method it is not modifying the correct type:
it modifies the enclosing method's signature instead of modifying the
lambda's signature.

As lambdas do not have an ExecutableType, the right thing is probably
to not modify the enclosing type.
However, I didn't see a way to determine from a parameter symbol
whether it is a lambda parameter or a normal method parameter.

Also, are the expected outputs for the referenceinfos/ test correct?
For a lambda within a field, the type annotation is currently lost.
Where should it show up? On the field? In the instance initializer?

I pushed a changeset to type-annotations with an ugly fix for the NPE
and the expanded test cases:

cu, WMD.

On Thu, Dec 5, 2013 at 7:47 PM, Alex Buckley <alex.buckley at> wrote:
> Starting at JDK8 b91, and continuing through b118, this innocuous program
> crashes javac:
> --
> import java.lang.annotation.*;
> import java.util.function.*;
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.TYPE_USE)
> @interface TA {}
> class LambdaFormal {
>   IntUnaryOperator x = (@TA int y) -> 1;
> }
> --
> with:
> java.lang.NullPointerException
>         at
>         at
>         at$JCLambda.accept(
>         at
> ...
> This is weird because I'm sure I've annotated lambda formals in this fashion
> since b90. It's due to TYPE_USE - if TA's target is PARAMETER, then the
> program rightly compiles, while if TA's target is FIELD, you get the
> expected applicability error.
> Before I file a P2 bug for this, can anyone add some color to the situation?
> Alex
> P.S. With a TA target of TYPE_USE, b90 produces a class file without the
> expected RuntimeVisibleTypeAnnotations attribute for @TA. But that's less of
> a concern right now.


More information about the type-annotations-dev mailing list