RFR: 8370800: Downgrade cant.attach.type.annotations diagnostics to warnings [v8]

Liam Miller-Cushon cushon at openjdk.org
Wed Dec 10 09:00:25 UTC 2025


On Sun, 9 Nov 2025 18:30:53 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Hi, please consider this fix for [JDK-8370800: Downgrade cant.attach.type.annotations diagnostics to warnings](https://bugs.openjdk.org/browse/JDK-8370800).
>> 
>> As discussed in the, this reduces the compatibility impact of these diagnostics for builds that deliberately omit transitive annotation dependencies, for example if they are only referenced through javadoc `@link` tags, or by frameworks that conditionally load the classes.
>> 
>> The PR changes the existing error diagnostic to an unconditional warning. Another alternative would be to make it an optional xlint diagnostic, perhaps as part of `-Xlint:classfile`, or as another category.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Complete symbols returned by getAllMembers

I'm still unsure what the best approach here is.

> in practice the issues that have come up are all with method (and maybe fields), but not classes. I think eagerly attaching TAs to classes and only lazily attaching TAs for methods/fields would address the complaints

I also recognize there are other downsides of using field/method completers (including that it would make it hard to use them for other things in the future, and it requires a lot of care to ensure completion happens at the right times).

I don't see a clear favourite among the options:

1. Completers (see above)
2. Downgrade to warnings 
    * missing types are ignored, annotations are missing from model elements
    * some clients will be running with `-Werror` and will want to be warnings clean, which is an issue from library owners that are currently relying on the lenient handling of missing types referenced by fields/methods. Putting this behind an `-Xlint:` category doesn't full solve that problem
3. Do nothing for now
    * avoids implementation tradeoffs around using completers, or downgrading diagnostics for missing classes
    * doesn't address the problem for library owners

I think (1) best addresses the problem that's been reported by library authors. But I am not sure if that's going to have a bug tail of subtle completer issues, or cause problems later if there's another use-case for completers on fields/methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28018#issuecomment-3636033828


More information about the compiler-dev mailing list