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.buck...@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
