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

[Alex Buckley]

On 2/25/2020 8:16 AM, Remi Forax wrote:
> 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).

In the context of JUnit, the module-info.java file of a test module does 
not define a transitive dependency or define a service. It opens a 
module and adds some direct dependencies -- clauses that are expressible 
with the current command line options. Other test frameworks may want to 
arrange things that are not expressible with the current command line 
options today, but there is no guarantee that --patch-module-descriptor 
would be able to handle those things either, e.g., if the test module 
wishes to remove dependencies or exports of the main module rather than 
always add them. But for what JUnit needs, a build tool plugin could be 
created today.

>> 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. 
> --patch-module-descriptor is a way to get that.

And there are other ways, where the build tools (or their plugins) take 
responsibility for arranging the test-time module graph. This may 
require more work on the part of build tool/plugin maintainers than 
simply telling their users to write JDK command line options in the 
middle of a config file.

Alex