javac crash for annotation on lambda formal parameter type

[Vicente-Arturo Romero-Zaldivar]

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/

On 10/12/13 19:55, Vicente-Arturo Romero-Zaldivar wrote:
> On 10/12/13 18:36, Werner Dietl wrote:
>> >From Vicente's description I took away that the problem is too
>> fundamental for me to work around in type-annotations.
>
> Hi Werner,
>
> I will submit a public webrev shortly.
>
>>
>> Can we get the, admittedly ugly, hack I have in type-annotations into
>> tl? It at least prevents this particular crash.
>> I updated type-annotations/langtools to make diffing easier.
>
> I should push the patch by the end of this week so the crash should be 
> fixed.
>
> Thanks,
> Vicente
>
>>
>> It is a pity that this means that the compiler is not generating correct
>> bytecode for type annotations within lambdas within field initializers.
>>
>> cu, WMD.
>>
>> On 13-12-10 01:23 PM, Alex Buckley wrote:
>>> On 12/8/2013 3:36 PM, Vicente-Arturo Romero-Zaldivar wrote:
>>>> I have created this bug entry to track this issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8029787
>>>>
>>>> I think this should be deferred for now, but Alex if you think that 
>>>> this
>>>> should be fixed asap feel free to raise the priority to P2 and 
>>>> provide a
>>>> justification.
>>> Vicente, thanks for looking at the issue. I see that JDK-8029787 is now
>>> closed as a duplicate of JDK-8029721, which is itself a P2.
>>>
>>> Werner, FYI, we (Oracle) are now only working on P2s and P1s for JDK 8,
>>> and all P2s must be resolved by 12/13. After 12/13, it's P1s only;
>>> everything else gets deferred to an update release or JDK 9.
>>>
>>> Alex
>