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

[Christian Stein]

Hi Alex,

On Fri, Feb 14, 2020 at 7:06 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> [...]

Now, I am not "proposing" `--patch-module-descriptor` for a future JDK.
> I am recognizing that certain use cases involve changing a module's
> dependences and encapsulation in a tightly scoped way.


I can clearly envision the superpowers of the not (yet) proprosed
`--patch-module-descriptor` option unleashed upon the
Modular Testing World solving the long-standing issue of
resorting to either the class-path or the command-line when
it comes to in-(tra)-module (white box) testing. [0]

Let's explore the feature set of such an option and its limits together.
Looking forward to help with and test-drive that solution.

Three or two years ago, I contributed the "tester plugin" to pro [1].
Pro is a Java build tool that works seamlessly with modules and was
created be Rémi Forax.
That pro tool already performs such a merge action when for in-(tra)-
module (white box) test modules (can you please specify simple
token for such a type of module?!).
Here is the relevant implementation [2] which may guide us
when exploring the feature set. I guess, Rémi will comment on
this topic, too. As he is, if I recall correctly, "the father of the idea".

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...


> If JUnit creates its own module layer, [...]


No, we don't. We "just" make use of the ModuleReader when
scanning a module for potential test classes. That logic [3] is
shipped in a MR-JAR since two years ago and works flawlessly.


> [...] then it can define module descriptors at run time

how ever it likes [...]


Like said before, I think, that's too late in the build game. And
still we had to require the user to pass the extra information
to our framework ... in non-standard manner. Using the manually
merged in-(tra)-module (white box) test modules works for us
since day one of Java 9.


> . It's not clear to me if
> Christian & co. have looked into java.lang.ModuleLayer,
> java.lang.module.Configuration, and java.lang.module.ModuleFinder.

If they have, we'd love to hear their experiences.


Yes, I did: [4]

Works like a charm a test runtime when you want to open a module
to the modules of the build tool. Or here, as you might have guessed,
read the extra information required for testing provided by the user
in a `module-info.test` [5] formatted file. The major drawback is the
simple text format that this `module-info.test` uses: brittle as best.

Summarizing, I like the _not_ proposed `--patch-module-descriptor` option.

Cheers,
Christian

[0]:
https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html#white-box-modular-testing-with-module-infojava
[1]: https://github.com/forax/pro/tree/master/plugins/tester
[2]:
https://github.com/forax/pro/blob/2ddd9425cb95617b6dfd6c7d077ed387a5f6809c/src/main/java/com.github.forax.pro.helper/com/github/forax/pro/helper/ModuleHelper.java#L338-L378
[3]:
https://github.com/junit-team/junit5/blob/master/junit-platform-commons/src/main/java9/org/junit/platform/commons/util/ModuleUtils.java
[4]:
https://github.com/sormuras/junit-platform-isolator/tree/master/junit-platform-isolator-java-11/src/main/java/de/sormuras/junit/platform/isolator
[5]:
https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html#white-box-modular-testing-with-extra-java-command-line-options