I've seen that in a project with module-info.java, maven adds the modular jars (containing module-info.class or manifest property Automatic-Module-Name ), to the --module-path, and the rest of the jars to the -classpath.

But the spec states:

[...] It does not, however, mean that code in a named module can access types in the unnamed module. A named module cannot, in fact, even declare a dependence upon the unnamed module. This restriction is intentional[...]

From what I know packages from non-modular jars of the classpath are added to the unnamed module.

Since the modular project sources are not allowed to access types from the unnamed module, what is the purpose of adding any jars to the -classpath in the above case?

1

There are 1 answers

3
Robert Scholte On BEST ANSWER

It is more subtle. The Apache Maven plugins that need to understand the module-path make use of Plexus Java. This can build up a tree of all the required modules, based on the module descriptors. It understands the module-info file, the Automatic-Module-Name, but also the filename based automatic modules. Ideally nothing should end up on the classpath, it often means you're pulling in too much (transitive) dependencies. However, in some cases jars cannot end up on the module path (filename cannot be transformed to modulename, filename collisions), so you need other tricks. https://openjdk.java.net/jeps/261 shows a list of additonal arguments you can provide to interact between modulepath and classpath/files.

I could have gone for the easy solution (put everything on the modulepath, let javac/java decide what it needs), however for Maven I've decided to go for a clean modulepath: only put jars on the module path that are really used. The rest ends up on the classpath.