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

Liam Miller-Cushon cushon at
Mon Apr 11 20:40:55 UTC 2022

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.


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

> Hello,
> I'm interested in trying to help with
> (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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the compiler-dev mailing list