RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

Alex Buckley alex.buckley at oracle.com
Fri Feb 14 21:29:36 UTC 2020


On 2/14/2020 11:29 AM, Christian Stein wrote:
>> A different way to address those use cases would be to ship the
>> logic just described for `--patch-module-descriptor` in a launcher
>> offered by the test framework itself.
>  
> That's too late in the build game. You already need this merged
> descriptor at compile time. And you need the user to define the
> additional elements (modifiers and directives), as no build tool
> may infer them always correctly by inspecting the test sources...

Fair point, and thanks for reminding me about your "Testing In The 
Modular World" document.

The thing I'm having trouble with is that javac already lets you specify 
the --add-reads options on org.junit.jupiter.api & friends that are 
needed to compile test code. If Maven expects the user to painfully 
configure the POM to pass --patch-module-descriptor to javac, why can't 
the POM offer an easy way to make Maven itself (in the `test-compile` 
phase?) pass some defined-behind-the-scenes --add-reads options?

Similarly, at run time, you propose to always open the main module to 
the same org.junit.platform.commons module -- `module-info.test` is more 
or less the same for every JUnit project -- so why doesn't the POM have 
an easy way to let Maven itself (in the `test` phase?) pass --add-opens 
to java?

There are no new modularity "primitives" here (by which I mean features 
of the module system itself, such as open modules) ... there is just 
detailed configuration which, in the testing context, should be done by 
the build tool rather than the user.

Alex


More information about the jigsaw-dev mailing list