Hi Alex, On Fri, Feb 14, 2020 at 7:06 PM Alex Buckley <alex.buck...@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
