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

[Robert Scholte]

I am aware that the current patch concept is already complicating things.
Apart from the impact of the requested implementation, the information+options should all be available already: the patch module descriptor should be considered as an alias for some related commandline options.


With a tool like Maven it is already possible to compile and run patched modules, but in case of requiring java.* modules it is very awkward that it requires additional configuration in the pom instead of some dedicated module descriptor, which feels most natural.
You'll get an exception like: package java.sql is declared in module java.sql, but module some.module.name does not read it
And the first thing that comes to mind is: add java.sql to the (main) module descriptor. But this should not be done.

Other options to avoid this would be: 
- source code scanning to figure out all used modules. To me not an option: way too expensive/resource consuming.
- by default add all java.* modules, since they should be available anyway.
All other solutions will be a tool specific solution, even though they're struggling all with the same problem.

To me having the correct (main) module descriptor should be the ultimate goal. People should not be tempted to apply workarounds on this descriptor to make things work for tests (even though those module are for sure part of the java runtime)
Especially because of the impact wrong module descriptors would have and which cannot be adjusted.

thanks,
Robert
On 13-2-2020 00:12:02, Alex Buckley <alex.buckley at oracle.com> wrote:
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