RFE simplify usage of patched module

Robert Scholte rfscholte at apache.org
Tue Feb 4 20:08:07 UTC 2020


background:
while developing the maven-compiler-plugin I've often resisted for adding module descriptors to the test-classes. 
Test classes won't result in a deliverable.
I've been able to construct the right set of arguments for the compiler based on the pom.xml and the module descriptor and I hadn't seen an example yet that should change my opinion.

However, recently I received a small project that required java.sql, but only during test. Because they didn't really understand why the test-compilation failed, this module was added to the module descriptor with a comment ( /* only for test */ )
My advice was replacing it with the following to the maven-compiler-plugin:
<execution>
  <id>default-testCompile</id>
  <configuration>
    <compilerArgs>
      <compilerArg>--add-modules=java.sql</compilerArg>
    </compilerArgs>
  </configuration>
</execution>


But something similar needs to happen for surefire, to run the tests.

This is sadly one example where the user is forced to understand these additional flags. I could try to solve this with a custom (Maven) solution to avoid the need for flags configuration, but that would make it tool specific, whereas I believe this should be solved by the JDK.

What might have helped would be something like this:
src/test/java/module-info.java
[....] {
  requires java.sql;
}

I've put [...] on purpose, because in this case I don't think the module should have the same name as the "main" module descriptor, because it is that module. An anonymous module is already better, but that is not allowed in the descriptor. 

One solution that might fit here is the introduction of a new modifier: patch
patch module some.module {

   requires java.sql;
}
This describes clear the purpose of the module, and as the "patch" already implies: it should be handled with care.
Allowing such module descriptor should help adopting the modular system faster. It doesn't require the knowledge of the module related flags, the buildtool can solve it. As the developer is already familiar with the main module descriptor, adding a patched module descriptor when required is just a simple step.

Both java and javac could benefit from this change, and you might consider to not allow to package with a patched module descriptor.

regards,
Robert Scholte


More information about the jdk-dev mailing list