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 option. This makes modules

Answer 1

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 , -p 

Specify where to find application modules

--class-path , -classpath , -cp 

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.