javac crash for annotation on lambda formal parameter type

[Vicente-Arturo Romero-Zaldivar]

Hi Joel,

Thanks for your comments.

On 11/12/13 10:10, Joel Borggren-Franck wrote:
> Hi Vicente,
>
> FWIW I think this looks fine, _but_ you should get a review from someone
> more experienced with the later phases of javac.

I have this already covered, please check links in the bug entry.

>
> Kudos for the well documented fix.

Thanks.

>
> 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?

Right now this is not happening, it's true that if there are changes in 
the future then this code may fail, but that's part of the process. I 
was thinking about using a weak hash map in Attr, but this approach is 
probably too much for a, for the moment, simple issue.

Vicente.

>
> 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/
>>