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

Laird Nelson ljnelson at gmail.com
Fri Jul 14 13:26:26 UTC 2023


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

> I tried a
> simple testcase, where a use in module "use" uses an annotation from
> different module "lib", and the usages is from classfile:
>
>
> https://github.com/lahodaj/jdk/blob/e74368cb72790a399f3bb28c0dde2146d015757e/test/langtools/tools/javac/modules/AnnotationsAndMultipleModules.java
>

Would it matter if "different module" were the/an unnamed module? And if
"use" were a patched module?

In case it turns out to matter, the scenario is one that is commonly set up
by Maven's JUnit test machinery unless you actively work against it: at
test time, unit test code under src/test/java is automagically patched into
(via --patch-module) your project's "main" module (M) (whose classes reside
conventionally under src/main/java). The command line contains
--module-path "/path/to/M", --add-reads M=ALL-UNNAMED, and --add-opens
M/p=ALL-UNNAMED, and --add-modules M (if I've typed all that properly).
JUnit itself, though modular, is on the classpath. The annotation in my
example (q.C) is actually org.junit.jupiter.api.Test, if it matters. The
net effect is (not defending it, just noting) M's module-info does not have
to explicitly read any JUnit module, but your project's JUnit-based unit
test code can nevertheless "see" package-private methods etc. in M as if it
were a proper member of M.

In this case, in such an environment, if you
access @org.junit.jupiter.api.Test (annotating a method in your unit test
under src/test/java, patched in to M), its type will be erroneous. Or so I
am observing.

I'll see if I can put together a reproducer but this is not at all high
priority for me. I'm also getting the strong sense here that this is
somehow likely pilot error in some way, though I'm not sure on what input.

Thanks for your time,
Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230714/bffa4a2d/attachment.htm>


More information about the compiler-dev mailing list