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

[Liam Miller-Cushon]

On Wed, 29 Oct 2025 14:17:13 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:
> 
>   Update examples.not-yet.txt

I added a comment to https://bugs.openjdk.org/browse/JDK-8370800 with some more analysis. I think the core of the new behaviour that is surprising and potentially undesirable is

> javac is more eagerly completing symbols that are referenced in the API of any libraries referenced by the current compilation, if those APIs have type annotations

I wonder if a better approach here is to continue to report `cant.attach.type.annotations` as an unconditional error, but to defer the work down by `addTypeAnnotationsToSymbol` until the symbol is completed, instead of doing it unconditionally when annotations are completed after reading the class.

That would mean that if the only place javac needing a missing class was to attach type annotations, a regular compilation would succeed, but a compilation with an annotation processor that tried to read those type annotations would still get a `cant.attach.type.annotations` error.

I have uploaded a new draft where `addTypeAnnotationsToSymbol` is deferred until the annotated symbol is completed.

@lahodaj do you think that approach might have any merit?

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

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