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

[Liam Miller-Cushon]

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

Another place this could be informed by the specification is the specification of runtime behaviour when loading and linking classes with references to missing classes. I don't have as good an understanding of JLS 12 and JVMS 5 as I'd like, but it was surprising to me how tolerant the runtime behaviour is of missing classes.

For example, the following program successfully calls a method whose descriptor references a return type that doesn't exist.


=== ./A.java ===
class A {}
=== ./B.java ===
import java.util.List;

class B {
  A f(List<A> xs) {
    return null;
  }
}
=== ./T.java ===
import java.util.List;

class T {
  public static void main(String[] args) {
    new B();
    new B().f(List.of());
    var a = new B().f(List.of());
    boolean b = a == new Object();
    System.err.println("hello");
  }
}



$ javac -g *.java; rm A.class; java T
hello

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

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