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

[Josiah Noel]

I also maintain multiple annotation processors (Avaje Inject
<https://avaje.io/inject> and Validation <https://avaje.io/validator/>)
that (futilely) try to scan type-use annotations from external dependencies
for some features. A backport would be nice to have so the import features
could work in earlier versions.

On Thu, Jul 25, 2024 at 10:12 PM Manu Sridharan <manu at sridharan.net> wrote:

> 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/20240726/203146f0/attachment-0001.htm>