Redo of backport of JDK-8225377 (type annotations are not visible to javac plugins across compilation boundaries)

Liam Miller-Cushon cushon at google.com
Wed Jul 24 23:30:04 UTC 2024


Hi,

I would like to raise the possibility of re-doing the backport of
JDK-8225377 to JDK 21.

To briefly recap the issue, JDK-8225377 was a fix made in JDK 22 which
causes javac to attach type annotations read from bytecode with their
corresponding type mirror. Prior to that change javac read the annotations
from the class file, but did not attach them to the corresponding type, so
annotation processors were unable to retrieve them from the type mirror
API. There is more detail in the bug [1] and PR [2].

There was an attempt to backport the fix to earlier release trains, but
there was some compatibility impact to micronaut [3][4], and the change was
backed out [5]. (The issue affecting micronaut has since been fixed [6].)
The compatibility impact from the change comes from the fact that
`AnnotatedConstruct#getAnnotationMirrors` correctly reports annotations
that were previously being ignored, and `TypeMirror#toString` correctly
includes the annotations in the string representation that were previously
omitted. This change affects existing code, for example if an annotation
processor doesn't handle type annotations and was relying on the bug
causing them to be skipped, or code that expects `TypeMirror#toString` to
omit type annotations and relies on stable `toString` input to use as a key.

There is also some ongoing impact from the presence of the bug. Annotation
processors that want to process type-use annotations are unable to retrieve
annotations from classes on JDK versions prior to 22, and have no
workaround to access those annotations without delving into javac
internals. A specific example is the JSpecify annotations [7], which I
would like to make possible for annotation processors to access when they
appear on libraries read from the classpath.

I understand that redoing the backport would require filing a 'REDO
BACKPORT'  issue and creating a new CSR associated with that bug.

Before I do that, I'm curious if anyone on the list has input on the idea
of redoing the backport, and of how to evaluate that tradeoff between the
risk of the compatibility impact and the benefit of fixing the bug in
earlier release trains?

Thanks,
Liam

[1] https://bugs.openjdk.org/browse/JDK-8225377
[2] https://github.com/openjdk/jdk/pull/16407
[3] https://bugs.openjdk.org/browse/JDK-8323093
[4] https://github.com/micronaut-projects/micronaut-core/pull/10293
[5] https://bugs.openjdk.org/browse/JDK-8322883
[6] https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.2.3
[7] https://jspecify.dev/blog/release-1.0.0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240724/e2d6b716/attachment.htm>


More information about the compiler-dev mailing list