concept class path in category java

This is an excerpt from Manning's book The Java Module System. Login to get full access to this book.

As a consequence, the class path, used to specify JARs or plain .class files for the compiler and JVM, works as on Java 8 and before. Even modules on the class path behave just like non-modular JARs. The underlying assumption is that the class path is in charge of accessing artifacts that want to be turned into the ball of mud discussed in section 1.3.

Listing 5.1 Loading resources: all successful because they’re on the class path

Class<?> anchor = Class
    .forName("monitor.resources.opened.Anchor")    #1  

URL pack = anchor.getResource("file.txt");    #2  

URL root = anchor.getResource("/file.txt");    #3  

URL meta = anchor.getResource("/META-INF/file.txt");    #4  

URL bytecode = anchor.getResource("Anchor.class");    #5  

copy

The class path makes no distinction between plain and modular JARs: if it’s on the class path, it ends up in the unnamed module. Similarly, the module path makes little distinction between plain and modular JARs: if it’s on the module path, it ends up as its own named module. (For plain JARs, the module system creates an automatic module; for modular JARs, it creates an explicit module according to the description.)

To understand the rest of this chapter as well as to perform a modularization, it’s important to fully internalize that behavior. Table 8.1 shows a two-dimensional recast. Not the type of JAR (plain or modular) but the path it’s placed on (class path or module path) determines whether it becomes part of the unnamed module or a named module.

Table 8.1 It isn’t the type of the JAR but the path it’s placed on that determines whether a class ends up as a named module or in the unnamed module. (view table figure)

	Class path	Module path
Plain JAR	Unnamed module (section 8.2)	Automatic module (section 8.3)
Modular JAR		Explicit module (section 3.1.4)

When deciding whether to place a JAR on the class path or the module path, it’s not about where the code comes from (is the JAR modular?); it’s about where you need the code to be (in the unnamed or a named module). The class path is for code you want to go into the ball of mud, and the module path is for code you want to be a module.

But how do you decide where code needs to go? As a general guideline, the unnamed module is about compatibility, enabling projects using the class path to work on Java 9+; whereas automatic modules are about modularization, allowing projects to use the module system even if dependencies aren’t yet modularized.

Figure 8.2 Launched with all application JARs on the class path, the module system builds a module graph from the platform modules (left) and assigns all classes on the class path to the unnamed module (right), which can read all other modules

Armed with that understanding, you’re well prepared to run simple, mon-modular applications from the class path. Beyond that basic use case, and particularly when slowly modularizing an application, the subtleties of the unnamed module become relevant, so we look at them next.