<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I also maintain multiple annotation processors (Avaje <a href="https://avaje.io/inject">Inject</a> and <a href="https://avaje.io/validator/">Validation</a>) 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.</div><input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false,"sms":false},"attachments":{},"compose-id":"1"}"></div></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Thu, Jul 25, 2024 at 10:12 PM Manu Sridharan <<a href="mailto:manu@sridharan.net">manu@sridharan.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr">
Hi all,</div><div dir="ltr"><br></div><div dir="ltr">I wanted to chime in to support the idea of re-doing the backport of this fix. I’m a primary maintainer of NullAway (<a href="https://github.com/uber/NullAway" target="_blank">https://github.com/uber/NullAway</a>) 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.</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">Best,</div>Manu </div><div dir="ltr"><br></div><div dir="ltr"><br></div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Jul 24, 2024 at 16:30:04, Liam Miller-Cushon <<a href="mailto:cushon@google.com" target="_blank">cushon@google.com</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
<div dir="ltr">Hi,<br><br>I would like to raise the possibility of re-doing the backport of JDK-8225377 to JDK 21.<br><br>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].<br><br>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.<br><br>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.<br><br>I understand that redoing the backport would require filing a 'REDO BACKPORT' issue and creating a new CSR associated with that bug.<br><br>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?<br><br>Thanks,<br>Liam<br><br>[1] <a href="https://bugs.openjdk.org/browse/JDK-8225377" target="_blank">https://bugs.openjdk.org/browse/JDK-8225377</a><br>[2] <a href="https://github.com/openjdk/jdk/pull/16407" target="_blank">https://github.com/openjdk/jdk/pull/16407</a><br>[3] <a href="https://bugs.openjdk.org/browse/JDK-8323093" target="_blank">https://bugs.openjdk.org/browse/JDK-8323093</a><br>[4] <a href="https://github.com/micronaut-projects/micronaut-core/pull/10293" target="_blank">https://github.com/micronaut-projects/micronaut-core/pull/10293</a><br>[5] <a href="https://bugs.openjdk.org/browse/JDK-8322883" target="_blank">https://bugs.openjdk.org/browse/JDK-8322883</a><br>[6] <a href="https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.2.3" target="_blank">https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.2.3</a><br>[7] <a href="https://jspecify.dev/blog/release-1.0.0" target="_blank">https://jspecify.dev/blog/release-1.0.0</a><br></div>
</blockquote>
</div></div>
</blockquote></div></div>