Bug ID: JDK-8346471 [REDO BACKPORT] type annotations are not visible to javac plugins across compilation boundaries

Type: CSR
Component: tools
Sub-Component: javac

Priority: P3
Status: Closed
Resolution: Approved
Fix Versions: 17-pool,21-pool

Submitted: 2024-12-17
Updated: 2025-03-12
Resolved: 2025-03-08

Summary
-------

Update javac's implementation of `TypeMirror` to allow accessing type use annotations on types loaded from class files.

Problem
-------

The implementation currently does not associate type use annotations loaded from class files with the corresponding types. This means that `TypeMirror` APIs including `getAnnotationMirrors` and `toString` do not accurately report type use annotations for types loaded from class files.

Solution
--------

If a type annotation is present on a type read from a class file, the implementation should associate the annotation with its type.

Specification
-------------

No specification change; behavioral change only.

[~cushon], right approved with the same non-filtering of toString as used for the feature release; thanks.
12-03-2025
Thanks Joe! My understanding is that the backport has been approved as-is (without the discussed modifications around toString behaviour or -XD flags). I will update the PR for JDK-8341779 and the linked backports for review, and tentatively target 21.0.8. Deferring changes to 17u for at least one release sounds good to me.
11-03-2025
After internal deliberations, I'm moving this request to Approved with the following caveat: at least for Oracle's releases, any fix for 17u will occur at least one release after a fix in 21u.
08-03-2025
Hi [~cushon], I've asked someone internally here who was involved in the unexpected side-effects of the first time the fix was made to re-assess making the change again, but haven't heard back yet. I'll re-ping.
04-02-2025
Is there any more feedback on the draft, including on how best to re-asses the compatibility impact, or on alternatives (adding internal flags to configure the behaviour, or customizing the fix to not apply to toString methods)? [As a procedural question, should I 'finalize' this to get another CSR review?]
03-02-2025
> Braininstorming-level kind of comment: to reduce the behavioral compatibility impact, if the issue from the the toString results rather than the presence of the type annotations per se, it should be a "small matter of programming" to filter out selected type annotations from the toString results, assuming there is access to a "generated from a class file" bit. It's definitely possible technically, here's a demo: https://github.com/cushon/jdk21u-dev/commit/82ab4c5f2d8c08c7f887ad25967bf28237cd08ca I'm not certain that's the best option overall. Processors could be impacted by the presence of the bug both in toString, and other APIs. Existing processors that rely on the presence of the bug in toString and other APIs could be impacted if the bug is fixed. It's possible that most of the benefit would come from fixing non-toString APIs, and most of the risk would be from changes to toString, but I'm not sure how to quantify that.
21-01-2025
Braininstorming-level kind of comment: to reduce the behavioral compatibility impact, if the issue from the the toString results rather than the presence of the type annotations per se, it should be a "small matter of programming" to filter out selected type annotations from the toString results, assuming there is access to a "generated from a class file" bit.
21-01-2025
Moving to Provisional, not Approved. Thanks for taking another pass at this one [~cushon]. Before this can be approved, we'll need to re-assess the behavioral compatibility impact possibilities given experiences the first time around.
06-01-2025
This CSR proposes a redo of the backport of JDK-8323093 to JDK 21. JDK-8323093 was first fixed in JDK 22, and backports were pursued, but the initial backports were backed out due compatibility impact. (The issue affecting micronaut has since been fixed.) Since the initial backports, there has been more experience with these changes in JDK 22 and newer versions. There is also ongoing impact from the presence of the bug in older releases that would be mitigated by this backport. 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 using supported APIs. See also discussion in compiler-dev@ in https://mail.openjdk.org/pipermail/compiler-dev/2024-July/thread.html#27344 and https://mail.openjdk.org/pipermail/compiler-dev/2024-August/thread.html#27446 One potential approach could be to backport the changes but disable the logic by default, with a javac flag -XD flag to enable it, and then later consider enabling it by default after additional testing. That could also make it easier to stage the changes, since there are several related fixes here that should all be backported together if any of them area.
17-12-2024