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

[Manu Sridharan]

 Hi all,

I wanted to chime in to support the idea of re-doing the backport of this
fix.  I’m a primary maintainer of NullAway (https://github.com/uber/NullAway)
and we are working to better support checking of generic types and arrays
according to the JSpecify spec.  Due to JDK-8225377 we need to implement
workarounds based on internal APIs to read type annotations from bytecode
for JDK versions prior to 22.  We have implemented a few already, but fully
supporting all possible type annotation positions  (on nested generic
types, arrays, etc.) will be significant additional work.  A backport of
the fix for JDK-8225377 would save us a lot of time and make it much easier
for tools like NullAway to properly analyze and support these language
features.

Best,
Manu


On Jul 24, 2024 at 16:30:04, Liam Miller-Cushon <cushon at google.com> wrote:

> 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/20240725/ff01b558/attachment.htm>