javac crash for annotation on lambda formal parameter type

[Joel Borggren-Franck]

Hi Vicente,

FWIW I think this looks fine, _but_ you should get a review from someone
more experienced with the later phases of javac.

Kudos for the well documented fix.

Since code from Attr is frequently used in other phases, have you
thought about the possibility to get into a racy situation, say if LTM
calls back into Attr in an unexpected way?

cheers
/Joel

On 2013-12-10, Vicente-Arturo Romero-Zaldivar wrote:
> Hi all,
> 
> Please review this public review for bug [1] which can be found at [2].
> 
> Some background:
> 
> This bug was originally reported on the type-annotations-dev list. A
> code like this one:
> 
> import  java.lang.annotation.*;
> import  java.util.function.*;
> 
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.TYPE_USE)
> @interface  TA {}
> 
> class LambdaFormal {
>    IntUnaryOperator x = (@TAint  y) -> 1;
> }
> 
> 
> is producing a NPE in javac. Type annotations code assumes that any
> lambda expression will always have a method as it's owner, which is
> not always true.
> Nevertheless this approach can be considered correct because the
> compiler is creating a method symbol in cases where a method is not
> present, field declarations.
> 
> LambdaToMethod code was also expecting type annotations in one
> method, in the case of instance fields, in the first constructor, in
> the case of static fields in a fake <clinit> method.
> 
> What I have done here is to sync Attr with LTM so they use the same
> method depending on the particular case, see also the comments added
> in the patch.
> As a side result the method used by Attr and LTM classes is also
> used as a holder for type annotations, thus solving the current bug.
> 
> Probably this is not the ultimate solution to the problem. It should
> be studied if both type annotations and lambda code can be made more
> flexible such that they don't assume that lambda expressions have a
> method as it's owner, but I think that this is a good solution for
> now.
> 
> Thanks in advance for any comments,
> 
> Vicente
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8029721
> [2] http://cr.openjdk.java.net/~vromero/8029721/webrev_01/
>