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

[Christian Stein]

I agree with you, that the user (the build tool in most of the cases) should
stay in control which module descriptor is in effect for every module.

As my domain is testing, and I guess the majority of uses-cases is within
the realm of intra-module (white-box) testing, I'll expound on the topic
with
a complete example.


# GIVEN

- src/foo/main/java/module-info.java

module foo {
  // here be dragons
}

- src/foo/test/java/module-info.java

open $PATCH module foo {
  // here be same dragons as "main" foo declares
  requires org.junit.jupiter.api;
  requires org.assertj.core;
  requires java.sql;
}

Note, without the new $PATCH feature, you may just copy and paste
the "main" foo directives to the "test" foo module already today.


# WHEN

Compile the "test" module against the already compiled and optionally
packaged "main" module via:

javac --module-source-path src/*/test/java --patch-module
foo=out/classes/main/foo --module foo
jar --create --file out/modules/test/foo.jar -C  out/classes/test/foo .


# THEN

Execute JUnit Platform Console Launcher selecting the "test" foo module
and scanning it for tests. Here, all 3rd-party modules are already put into
a project-local "lib/" directory:

java
  --module-path out/modules/test/foo.jar:out/modules/main:lib
  --patch-module foo=out/modules/main/foo.jar
  --module org.junit.platform.console
  --scan-module foo


You see, there's still a command line switch required to get the patching
going. This command will (a) load the patched foo module, that one that
reads all modules required for testing and (b) resolve the classes under
test from the main module.

Yes, if someone (or the build tool) jars the test and main classes into
a single JAR file, you may create a "patched by default" module which
is no in control of the original author -- but, no change to what you
may already do today.

Cheers,
Christian


On Wed, Feb 5, 2020 at 5:44 PM Robert Scholte <rfscholte at apache.org> wrote:

> Hi Simone,
>
> to me the commandline doesn't change, so in your case the library.jar
> won't patch jetty-client.jar.
>
> It will only be patch as you already would do right now:
> java --module-path jetty-client.jar:library.jar:app.jar
> --module app/com.app.Main --patch-module jetty.client=/path/to/library.jar
>
>
> For Maven plugins I don't expect a lot of changes. I should probably use
> the name in the patched module descriptor instead of automatically choosing
> the main module descriptor, but these are little adjustments.
>
> Having a patched module descriptor in a jar might be awkward, hence maybe
> the packager shouldn't allow to add it, nor other tools to use it.
> But these are details open for discussion.
>
> Robert
> On 5-2-2020 08:57:53, Simone Bordet <simone.bordet at gmail.com> wrote:
> Hi Robert,
>
> On Wed, Feb 5, 2020 at 8:38 AM Robert Scholte wrote:
> >
> > Hi Simone,
> >
> > I understand your concern, but the patched module descriptor doesn't
> have to (or should not) replace the --patch-module option. This proposal is
> about the additional options you now need to put on the commandline, but
> which already fit in the module descriptor.
>
> I understand it does not replace --patch-module.
> I understand it adds the additional "requires", "opens", etc.
>
> But how do you stop a library that uses Jetty to ship a jar containing
> a patched module file that exports and opens things in Jetty that the
> Jetty authors did not want to export or open, without users knowing
> it?
>
> jetty-client.jar -> contains legit module-info.class
> library.jar -> contains patched descriptor that patches jetty-client
> app.jar -> my application with a legit module-info.class
>
> java --module-path jetty-client.jar:library.jar:app.jar --module
> app/com.app.Main
>
> With this command line, does the Java runtime parse and enable the
> patched descriptor contained in library.jar, opening up jetty-client?
> If not, how would you enable it in Maven?
>
> Am I missing something?
>
> Thanks!
>
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz
>