Combining -Xmodule and --add-reads
Sander Mak
sander.mak at luminis.eu
Tue Aug 23 14:23:29 UTC 2016
> On 23 Aug 2016, at 15:22, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
> I assume `--add-modules org.junit` will fix this, the reason being that no module requires org.junit.
Thanks Alan, that did the trick. Apparently this behavior changed for javac. Executing the test runs fine without --add-modules on org.junit, though:
java --patch-module undertest=mod-test \
--add-reads undertest=org.junit \
--add-exports undertest/undertest.mytestpackage=org.junit \
--module-path mods:lib-test \
--add-modules undertest,hamcrest.core \
-m org.junit/org.junit.runner.JUnitCore undertest.mytestpackage.WhiteboxTest
(hamcrest.core needs to be added explicitly since it's neither required nor used in --add-reads)
> On --add-reads failing then this is a scenario where javac and the runtime differ in behavior. I think Jon is planning a torture test to shake out such differences. I guess one could argue here that the --add-modules should be implied but that could be confusion too, esp. when the target module is not otherwise resolved.
Indeed, they seem to behave differently. On second thought, maybe not: in this case org.junit is resolved because of `-m org.junit/...`.
My vote would be on having --add-reads imply that the module is actually part of the resolved modules. Your caveat, while true, seems fairly inconsequential to me. In any case, the omission of `--add-modules` was hard to debug without an error message pointing out that --add-reads was referencing a non-resolved module.
Thanks for the help!
Sander
More information about the jigsaw-dev
mailing list