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.

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).

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.