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

[Remi Forax]

----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mardi 18 Février 2020 18:42:10
> Objet: Re: RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

> On 2/14/2020 9:34 PM, Christian Stein wrote:
>> Assuming `--patch-module-descriptor` was already available, the
>> org.astro test story would read:
>>
>> - org.astro/main/module-info.java:
>>
>> module org.astro {
>>    exports org.astro;
>>    requires java.logging;
>> }
>>
>> - org.astro/test/module-info.java:
>>
>> open /*test*/ module org.astro /*extends main module org.astro*/ {
>>    requires java.sql; // system-provided module needed by test code
>>    requires org.junit.jupiter; // framework reflecting entry-points
>>    requires org.assertj.core; // ...and more test-related modules
>> }
>>
>> A build tool now easily may detect that `--patch-module-descriptor`
>> is required at test compile and run time. It could infer it from the
>> same module name or simply by seeing a main and a test
>> `module-info.java` compilation unit within the sources of the
>> org.astro Maven-/Gradle-/pro-/Bach-/any-build-tool-"module".
>>
>> Build tools could pass the following argument to javac/java
>> while being in their test-scope tasks. Of course, implying that
>> org.astro/test/module-info.java is the current "primary" module
>> descriptor:
>>
>> --patch-module-descriptor org.astro=org.astro/main/module-info.java
>>
>> That's it.
>>
>> The primary test-relevant modular directives are enriched by
>> those of the main module as declared in org.astro/main/module-info.java
>> resulting effectively in a synthetic in-module test module descriptor that
>> resembles the inter-module test descriptor presented above:
>>
>> - SYNTHETIC test module for org.astro
>>
>> open /*test*/ module org.astro /*extends main module org.astro*/ {
>>    requires java.sql; // system-provided module needed by test code
>>    requires org.junit.jupiter; // framework reflecting entry-points
>>    requires org.assertj.core; // ...and more test-related modules
>>    //
>>    exports org.astro; // patched from org.astro/main/module-info.java
>>    requires java.logging; // patched from org.astro/main/module-info.java
>> }
>
> Good description of how the main module
> (org.astro/main/module-info.java) and the test module
> (org.astro/test/module-info.java) interact to form a test-scoped module.
> If a build tool has detected the presence of the test module, then the
> build tool can use javax.lang.model.element.ModuleElement to inspect the
> test module's declaration and infer what it requires, whether it's open,
> etc. Then, the build tool can enrich the main module by passing
> --add-modules, --add-reads, and --add-opens to javac/java while in a
> test scope.

Hi Alex,
no you can't because you can not reconstruct a module-info from the flags --add-modules, --add-reads, etc.

Those flags has been created to patch (mostly the JDK) module metadata so an application using the classpath can open/patch the JDK modules metadata enough to be able to run.
The semantics of a module-info is richer than the semantics of the flags, by example, there is no way to define a transitive dependency or to define a service.
I believe that roughly half of the semantics of a module-info has no equivalent in term of flags (and for good reason, those flags have not been created to describe a module-info).

> No need for --patch-module-descriptor in the JDK.

We need a way to express that the module graph when testing is different from the one when running in production.
--path-module-descriptor is a way to get that.

>
> Alex

Rémi