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

[Alex Buckley]

On 2/12/2020 1:08 PM, Robert Scholte wrote:
> To prevent these workarounds and to provide an easier way to patch a
> module via a dedicated descriptor will help keeping the module
> system cleaner.

It will lead to "split modules" on the modulepath, which will cause just 
as many maintenance headaches as split packages on the classpath. Yes, 
there is some maintenance benefit if a module explicitly declares that 
it patches (i.e. becomes part of) another module (which might then have 
to explicitly declare that it allows patching) ... but for a developer 
to understand the resulting module graph requires looking at everything 
on the modulepath, which is no better than having to look at everything 
on the classpath. In Java, a declaration -- whether a module, a class, 
or a method -- happens in one source file, and it's up to tools to 
rewrite declarations if other interesting source files are known to 
those tools.

> However, recently I've informed by this case: if the test sources
> use one of the java.* modules (that are not used by the main sources)
> the only correct way to solve it now is by adding the required flags
> by hand (and only to the test-compile configuration!). This is hard
> to explain and instead of diving into the specifications, 
> understanding what's happening, you'll see that they choose for the
> easy workaround: add this "test scoped" module as a required module
> to the module descriptor.

Is there nothing that Maven can do to make the test-compile 
configuration easier to create? Maven has all the source code at its 
fingertips, including knowledge of module directories which seem to 
declare the same module more than once because JUnit recommends it, yet 
still Maven makes the user laboriously write out the command line flags 
for patching?

Alex