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

[Alex Buckley]

Hi Christian,

On 2/7/2020 4:41 AM, Christian Stein wrote:
> This time, I created a project at [0] with a detailed description on its
> front page, i.e the README.md file.
> 
> [0]: https://github.com/sormuras/java-module-patching

To restate:

- You're saying that, today, it's brittle to copy directives from 
src/org.astro/main/java/module-info.java to 
src/org.astro/test/java/module-info.java. (And having copied them, you 
still need to `open` the test module and add some `requires`.)

- You suggest that, in future, there will still be a 
src/org.astro/test/java/module-info.java file which is of interest to 
test frameworks.

What you're hoping is that new syntax will let you invert the patching:

- Today, you set the module-path so that out/modules/test/org.astro.jar 
is the "primary" version of the module; then you redefine everything in 
it except module-info by overlaying out/modules/main/org.astro.jar.

- In future, you want to have out/modules/main/org.astro.jar as the 
"primary" version, and redefine only its module-info by specifying the 
sidecar out/modules/test/org.astro.jar. The sidecar would have some 
syntax to identify that its declaration of org.astro is strictly 
additive to the "primary" version. You would set the module-path to 
out/modules/main:out/modules/test:lib so that the module system (1) 
finds the "primary" version in out/modules/main and (2) augments its 
module-info with sidecars found in out/modules/test and lib. I assume 
some new command line option would enable or enumerate the sidecars 
explicitly, because obviously the dependences and exports of 
out/modules/main/org.astro.jar shouldn't depend on which JAR files 
happen to be lurking deep in the module-path.

Stepping back, the core issue is that once the true "primary" version of 
a module is built -- out/modules/main/org.astro.jar -- you don't want to 
change it. No build or test tool wants to physically rewrite its 
module-info to require test-time dependencies at test time, and then to 
not require such dependencies at release time. You want the module 
system to virtually rewrite the module-info instead. And that's already 
possible, as long as you put on your test-colored sunglasses and view 
out/modules/test/org.astro.jar as the "primary" version, and 
out/modules/main/org.astro.jar as the overlay ... once the tests have 
run, go back to viewing out/modules/main/org.astro.jar as the "primary" 
version. Introducing a new kind of module descriptor, with merging by 
the module system according to new command line options, seems like a 
lot of overhead that can already be worked around by tools at test-time.

Alex