Is it possible to mix --class-path and --module-path in javac (JDK 9)?

Question

When I compile a module that depends on other modules I've compiled previously I have to specify the --module-path <directory> option. This makes modules I depend on visible.

But at the same time I would also like to make some non-modular Jar files visible. However if don't make them automatic modules and just specify the --class-path some.jar right next to --module-path <directory>, then javac seems to ignore the claspath and throws "package yyy not found" and other "not found" errors.

I can understand that using --class-path and --module-path at the same (compile) time is illegal, but javac does not warn me against it in any way.

Dolce

It is possible to mix the two, can you share a minimum example that we can verify ? – Gayegayel

I can understand that using --class-path and --module-path at the same (compile) time is illegal, why is that so? – Hargis

Mixing is absolutely legal. However, modular jars cannot reference non-modular jars on the classpath. Automatic modules (non-modular jars on the modulepath) act as a bridge: modular jars can reference them, and automatic modules can read the classpath. – Vaticinal

Answer 1

You can use class path and module path in parallel, but there are a few details to consider.

Dependency Module Path ~> Class Path

Explicit modules (JARs with a module descriptor on the module path) can not read the unnamed module (JARs on the class path) - that was done on purpose to prevent modular JARs from depending on "the chaos of the class path".

Since a module must require all of its dependencies and those can only be fulfilled by other named modules (i.e. not JARs on the class path) all dependencies of a modular JAR must be placed on the module path. Yes, even non-modular JARs, which will then get turned into automatic modules.

The interesting thing is that automatic modules can read the unnamed module, so their dependencies can go on the class path.

Dependency Class Path ~> Module Path

If you compile non-modular code or launch an application from a non-modular JAR, the module system is still in play and because non-modular code does not express any dependencies, it will not resolve modules from the module path.

So if non-modular code depends on artifacts on the module path, you need to add them manually with the --add-modules option. Not necessarily all of them, just those that you directly depend on (the module system will pull in transitive dependencies) - or you can use ALL-MODULE-PATH (check the linked post, it explains this in more detail).

Mcelroy

Nicolai - your answer is correct but I think could be expanded to point out that the --add-modules option may be needed to ensure that the modules needed by class path code are resolved. The original question asks why javac fails and I assume this is because he/she is compiling code on the class path with references to classes in modules on the module path and just needs --add-modules to ensure that the modules are resolved. – Adsorbent

I think OP is trying to compile modular code with a non-modular dependency - either way, I added the other direction as well, just to make sure. – Mcelroy

@AlanBateman I tried to mix -classpath and --module-path during compilation and it fails even though I use --add-modules. javac -cp lib\* --module-path modules --add-modules simpleModule -d out @classes.txt where: lib-is folder with my jars, which I want to use in unnamed module; modules - contains a folder (folder name = simpleModule) with module-info.java inside; @classes.txt- list of classes for compilation (including modular classes from modules folder); simpleModule- module name from 'modules' folder. After I run this command I get package does not exist for jar in libdir – Aquilegia

@ZimboRodger Try quotes around lib/*, e.g. 'lib/*' or "lib/*". If that does not help, please open a new question. – Mcelroy

@Nicolai Did not help. Raised a question #49538480 – Aquilegia

You likely found this by now, and I might be misinterpreting the remarks, but automatic modules must be jars. A simple folder doesn't work. – Hibbler

how to do it in gradle project? – Ravelment

Answer 2

I believe using the --classpath and --module-path options at the same time is not illegal. It's possible to use both at the same time as even when you don't explicitly specify a classpath it defaults to the current directory.

Details from the javac -help message and javac tools docs -

--module-path <path>, -p <path>

Specify where to find application modules

--class-path <path>, -classpath <path>, -cp <path>

Specify where to find user class files and annotation processors

If --class-path, -classpath, or -cp aren’t specified, then the user class path is the current directory.

---

Edit: Thanks to @MouseEvent, I'd probably missed out the part in the question

However if don't make them automatic modules and just specify the --class-path some.jar right next to --module-path , then javac seems to ignore the claspath and throws "package yyy not found" and other "not found" errors.

If you don't make them automatic, it's treated as an Module System's unnamed module and -

A named module cannot, in fact, even declare a dependence upon the unnamed module. This restriction is intentional, since allowing named modules to depend upon the arbitrary content of the class path would make reliable configuration impossible.

Moreover, the unnamed module exports all of its packages hence the code in an automatic modules will be able to access any public type loaded from the classpath.

But an automatic module that makes use of types from the classpath must not expose those types to the explicit modules that depend upon it, since explicit modules cannot declare dependencies upon the unnamed module.

If code in the explicit module com.foo.app refers to a public type in com.foo.bar, e.g., and the signature of that type refers to a type in one of the JAR files still on the class path, then the code in com.foo.app will not be able to access that type since com.foo.app cannot depend upon the unnamed module.

This can be remedied by treating com.foo.app as an automatic module temporarily so that its code can access types from the class path, until such time as the relevant JAR file on the class path can be treated as an automatic module or converted into an explicit module.

Hargis

@MouseEvent Well that's true. I believe I missed that part of the question though previously and just answered the title. Edited to include that as well. Thanks :) – Hargis