RFR: JDK-8200166: Repeating annotations refering to to-be-generated classes don't work.
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Mar 28 15:49:13 UTC 2018
It seems surprising that a JCErroneous tree is used in this context. The
syntax is well-formed; the problem is a semantic one of "name not found".
"Expression not allowed" would seem to apply to something like
@Annot(System.out)
But
@Annot(DoesNotExist.class)
Should be "Name not found".
-- Jon
On 3/28/18 8:42 AM, Jan Lahoda wrote:
> Hi,
>
> javac in JDK 10 does not handle properly repeating annotations that
> contain attributes referring to classes that are generated by an
> annotation processor. E.g.:
> ---
> @Annot(Gen.class)
> @Annot(Gen.class)
> public class GeneratedInRepeating {
> }
> ---
>
> (where "Annot" is a repeating annotation, and "Gen" is a class
> generated by an annotation processor). This will fail to compile with
> (please see the bug for a complete example):
> ---
> ... error: expression not allowed as annotation value
> @Annot(Gen.class)
> ---
>
> The annotation processors won't run, so won't have a chance to
> generate the class.
>
> The issue is that Annotate.processRepeatedAnnotations creates a
> synthetic container annotation for the repeating annotation,
> constructs an AST for it and tries to attribute it (Annotate lines
> 821-832). But when the AST is created, as the class in the attribute
> value is missing, there is an JCErroneous tree generated. And then
> when Annotate.attributeAnnotationValue checks if the attribute's value
> is well-formed, it finds the erroneous tree and barks.
>
> The code was refactored in JDK-8181464, and was (AFAIK) accepting
> erroneous trees without producing the error before that.
>
> The proposed fix is to ignore the erroneous trees again. If there's an
> erroneous tree, there should have been an error produced already, so
> ignoring erroneous trees seems safe.
>
> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200166
>
> Thanks,
> Jan
More information about the compiler-dev
mailing list