Annotation type first encountered during ClassReader annotation parsing has wrong module?

[Liam Miller-Cushon]

On Fri, Jul 14, 2023 at 1:05 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Also, please note that the semantics of "Symtab.enterClass(ModuleSymbol
> msym, Name flatname)" is not "create a class called flatname in module
> msym", but "create a class called flatname accessible from module msym".
> This method follows the module rules, and looks into the modules the
> given module is reading, to find the correct package in the correct
> module to place the class. (It will fallback to placing the class into
> the given module, if there's no dependency where it would belong, which
> might be cause e.g. by improperly setup modules.)


This explains something I had been confused about :)

I have seen unexpected class.file.not.found for annotations referenced in
bytecode, where the module graph is ill-formed and the annotations aren't
supposed to be readable by the classes that reference them. I think that
explains why that happens.

I was curious why javac doesn't try to errors like what would be reported
during compilation when referencing a package that exists somewhere but
isn't readable (e.g. ''package X is declared in module Y, which does not
export it', and the other 'not.def.access' diagnostics). Are there
performance reasons? Perhaps it is too expensive to keep track of all
classes during classloading, including ones that shouldn't be readable, to
support that kind of diagnostic?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230714/8b924f26/attachment-0001.htm>