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

[Christian Stein]

// Hope this email will be technically associated as a reply for the
// "RFE simplify usage of patched module" thread.

I agree with Robert that a user-friendly and (build) tool-agnostic way
to express additional module directives and modifiers for testing
purposes only is ... a good thing to have.

As a workaround, I proposed, implemented and promoted a tool-agnostic
`module-info.test` file in [0] which, as of today, I no longer really like
that
much. The standard javac/java command options and arguments listed
as plain text lines in that file require users to know the module-related
options of javac/java meant to be primarily used by (build) tools.

Perhaps this discussion leads to a solution that supersedes the purpose
of "module-info.test" and renders
https://youtrack.jetbrains.com/issue/IDEA-222831
as no longer needed.

Robert Scholte wrote in
> http://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003880.html
>
> [...]
> What might have helped would be something like this:
> src/test/java/module-info.java
> [....] {
>   requires java.sql;
> }
>
> I've put [...] on purpose, because in this case I don't think the module
>
should have the same name as the "main" module descriptor, because it
>
is that module. [...]
>


This "solution" already works today. As described in [0] you may use the
existing module-info.java-DSL to describe such an additions (of extra
modules
needed for testing) by (I) repeating (most) directives from the "main"
module
descriptor and (II) add those needed for testing. This includes adding more
module modifiers, like `open` as well.

Using the same module name as `src/main/java/module-info.java`, of course.


> One solution that might fit here is the introduction of a new modifier:
> patch
> patch module some.module {
>
>    requires java.sql;
> }
> This describes clear the purpose of the module, and as the "patch" already
>
implies: it should be handled with care. [...]
>

Such a modifier would remedy the need to repeat directives from the "main"
module. It would effectively render step (I) from above not longer required.

Quote from [0]:
> Note: Copying parts from the main module descriptor manually is brittle.
> The “Java 9 compatible build tool” pro[1] solves this by auto-merging a
> main and test module descriptor on-the-fly.

Robert, you chose `some.module` as the name in this example? Is it
the same name as the "main" module?

Cheers,
Christian

[0]:
https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world#white-box-modular-testing-with-module-infojava

[1]: https://github.com/forax/pro