Approach for JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries

[Liam Miller-Cushon]

Hello again,

I'm inferring that there isn't overwhelming interest in reviewing a fix for
this :)

I'm still interested in whether anyone knows additional history here, or
has ideas about a simpler approach that I might be missing.

We're interested in this because we want to be able to define @Nullable as
a type-use annotation, instead of a declaration annotation. We rely on
annotation processors being able to inspect nullable annotations. Today, if
you define a method `@Nullable String foo();` and load it from the
classpath, an annotation processor can only see the annotation if it is a
declaration annotation on the method element (vs. type-use annotation on
the return type).

Even a limited fix would be helpful here. If the fix didn't cover the full
range of locations that type-use annotations can appear, but only the ones
where either a type use or declaration annotation can appear in source
(method declarations, fields, etc.), that would avoid surprises when
migrating from declaration annotations to type-use annotations.

Any thoughts on this are welcome.

Thanks,
Liam

On Tue, Mar 1, 2022 at 10:36 AM Liam Miller-Cushon <cushon at google.com>
wrote:

> Hello,
>
> I'm interested in trying to help with
> https://bugs.openjdk.java.net/browse/JDK-8225377 (type annotations are
> not visible to javac plugins across compilation boundaries).
>
> The issue described in the bug is that type annotations are not currently
> associated with some TypeMirrors loaded from the classpath. For example,
> TypeMirror#getAnnotationMirrors for the return type of a method does not
> report type annotations if the method was loaded from the classpath, but it
> does work for elements compiled from source in the current compilation.
>
> What I understand so far is:
>
> * the ClassReader reads in the full *TypeAnnotations attributes, including
> type paths
> * it creates a TypeAnnotationCompleter that saves the type annotations to
> the associated Symbol using Symbol#setTypeAttributes
> * the Symbol never associates the type annotations with their
> corresponding types, e.g. a MethodSymbol does not attach annotations to its
> return type
>
> It seems like there's logic missing to interpret the type paths read from
> class files and attach them to the appropriate type model element. This
> would be somewhat similar to the logic in core reflection that handles type
> paths and deals with reporting type annotations on the correct type [1].
>
> I'm wondering if I'm missing something, is there any prior work in javac
> to interpret type paths read from class files? If not, would there be
> interest in accepting that as a contribution? It would add some complexity
> and potential overhead, but I'm not seeing a good alternative to fix
> TypeMirror#getAnnotationMirrors for types read from class files.
>
> [1]
> https://github.com/openjdk/jdk/blob/d983d108c565654e717e2811d88aa94d982da2f5/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java#L194
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220411/8bba09d5/attachment.htm>