<div dir="ltr">I'm noticing that the type and element information for an AnnotationMirror's annotation type is erroneous when read from a class file via ClassReader in certain situations.<div><br></div><div>Specifically, consider:</div><div>* a module M with </div><div>* a class p.A with <br></div><div>* a method B annotated with </div><div>* a runtime visible annotation q.C where</div><div>* q (and therefore C) is not contained by M:</div><div><br></div><div>package p; // enclosed by module M<br></div><div>public class A {</div><div>  @q.C // q is not enclosed by M</div><div>  public void B() {}</div><div>}</div><div><br></div><div>Assuming I use javax.lang.util.Elements to get the ExecutableElement corresponding to B, this should (it seems to me) succeed (q.C's type's kind should be DECLARED):</div><div><br></div><div>TypeElement e = elements.getTypeElement("p.A");</div><div>// boring recipe for getting ExecutableElement for B from e omitted for brevity</div><div>assert TypeKind.DECLARED == executableElementForB.getAnnotationMirrors().get(0).getAnnotationType().getKind();</div><div><br></div><div>Instead it fails because the TypeKind in question is TypeKind.ERROR.  (Recall this is not source-related; I'm asking javax.lang.model.* to read valid already-compiled class files.)</div><div><br></div><div>From debugging into the compiler (I am a not very bright bull in a china shop), it seems to my naïve eyes that when the ClassSymbol for q.C is created as part of annotation bytecode reading, ClassReader assumes incorrectly that the module that should enclose q.C is M (see <a href="https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L535-L550" target="_blank">https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L535-L550</a>, and note that at #enterClass(Name)-time currentModule is M (<a href="https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L2468" target="_blank">https://github.com/openjdk/jdk/blob/jdk-20%2B36/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L2468</a>).</div><div><br></div><div>At any rate, the classfile attribute for the ClassSymbol for q.C when q.C is encountered/created via this annotation-bytecode-reading pathway is never set (probably because M is asked for its classes or packages or something and q.C is not among them, correctly, so the completion machinery doesn't know how to get it?), and that nullness seems to be the root cause for the TypeKind.ERROR being reported.</div><div><br></div><div>Also of note: if I ask for the TypeElement corresponding to q.C directly (via, say, elements.getTypeElement("q.C")) its ElementKind and associated TypeKinds are correct.</div><div><br></div><div>The situation in which I encountered this is rather convoluted so I don't have a simple executable reproducer ready to hand, but all the information that I know of is here.</div><div><br></div><div>Shall I file a bug, or work with someone offline, or is this expected behavior, or…? Thanks for everyone's time.</div><div><br></div><div>Best,</div><div>Laird</div></div>