A book discussing the module system of course focuses on the module path (see section 3.4). But the class path is still fully operational; and because you can use it side by side with the module path, it plays an important role during incremental modularizations. In other words, it still pays to know how it works.

Using the class path to load application JARs

Let’s look at this book’s example ServiceMonitor application as an example. It consists of multiple subprojects and has a few dependencies. In this scenario, all subprojects except the last one, monitor, have already been built and are present in the jars directory.

The following listing shows how to compile, package, and launch the application using the class path. Except for the new variants of some of the command-line options (for example, using --class-path, not -classpath), these are exactly the same commands as before Java 9.

Listing A.1 Compiling, packaging, and launching using the class path

javac
    --class-path "jars/*"   ①  
    -d monitor/target/classes   ②  
    ${java-files}   ③  
jar --create
    --file jars/monitor.jar   ④  
    -C monitor/target/classes .   ②  
java
    --class-path "jars/*"   ①  
    monitor.Main   ⑤  

Both the compiler and the runtime search the class path for the types they need. Which ones those are differ, though:

• Compiler —The compiler requires types that the code under compilation refers to. These are a project’s direct dependencies, or more precisely those types in the direct dependencies that are referenced from a file under compilation.
• Virtual machine —The JVM requires all types that the executed bytecode refers to. In general, these are a project’s direct and indirect dependencies; but due to Java’s lazy approach to class loading, it can be considerably fewer than that. Only types referenced by the code that is actually running are required, meaning a dependency can be missing if the code using it isn’t executed. The JVM also allows code to search JARs for resources.

Both javac and java have command-line options -classpath, -cp, and, since Java 9, --class-path. They generally expect a list of files, but it’s possible to use paths and wildcards that then get extended to such a list.

The class path since Java 9

Taking this backward compatibility into account, the question remains how the module system deals with types on the class path. In short, they all end up in the unnamed module, which the module system spins on the fly. This is a regular module, but it has some peculiarities, one of which is that it automatically reads all resolved modules. This is also true for modules that end up on the class path—they’ll be treated just like plain JARs, and their types will end up in the unnamed module as well, ignoring whatever their module declaration has to say. The unnamed module and modules on the class path are part of the migration story, which section 8.2 tells in full detail.