How many unnamed modules are created in Java 9?

Do I understand right that there is always only one unnamed module in JPMS?

In short

Generally speaking, no. But let's put it this way: If you place some or even all JARs on the class path and your application does not create class loaders to load any additional content, then there is only one unnamed module you need to care about.

In more detail

Every ClassLoader has its own unnamed module that it uses to represent classes that it loaded from the class path. This is necessary because the module system requires everything to be in a module.

As nullpointer's answer explains in detail, an application will by default use three separate class loaders. It is possible that it might spin up its own class loaders, for example to load plugins. If it doesn't do that, though, all application code will end up in the system/application class loader and hence in the same unnamed module. That's why there is typically only one you need to care about.

Does it mean that applications that were developed before Java9 and not updated for Java9 will be loaded as one unnamed module?

This has nothing to do with whether code (application, frameworks, libraries) targets Java 9 - it only depends on which path you place a JAR, on the class path or the module path.

If it's on the class path, it ends up in the unnamed module together with other class path content. This is true for plain JARs without module descriptor but also for modular JARs that contain one.

If it's on the module path, it gets its own module. If it's a modular JAR, it gets an explicit module as those described throughout the State of the Module System - plain JARs get turned into automatic modules (note the plural: one automatic module per JAR).

Do I understand right that there is always only one unnamed module in JPMS?

Yes, there is one unnamed module. The unnamed module is very similar to the existing concept of the unnamed package.

In implementations of the Java SE platform that use a hierarchical file system for storing packages, one typical strategy is to associate an unnamed package with each directory; only one unnamed package is observable at a time, namely the one that is associated with the "current working directory". The precise meaning of "current working directory" depends on the host system.

---

Does it mean that applications that were developed before Java9 and not updated for Java9 will be loaded as one unnamed module?

Yes, for those jars placed on the classpath would be treated as a single unnamed module. The bottom up migration with the concept of unnamed modules illustrates this with a similar example as:

Suppose, e.g., that the application shown above had originally been built for Java SE 8, as a set of similarly-named JAR files placed on the class path. If we run it as-is on Java SE 9 then the types in the JAR files will be defined in the unnamed module.

---

The actual question that can arise here is Which class loader is the unnamed module associated? The State of Module System about unnamed module states a clarification instead about this.

Every class loader, it turns out, has its own unique unnamed module, which is returned by the new ClassLoader::getUnnamedModule method. If a class loader loads a type that is not defined in a named module then that type is considered to be in that loader’s unnamed module, i.e., the getModule method of the type’s Class object will return its loader’s unnamed module. The module colloquially referred to as “the unnamed module” is, then, simply the unnamed module of the application class loader, which loads types from the classpath when they are in packages not defined by any known module.

The ClassLoader as revised in Java-9 states that:

The Java run-time has the following built-in class loaders:

• Bootstrap class loader: The virtual machine's built-in class loader...

• Platform class loader: ... To allow for upgrading/overriding of modules defined to the platform class loader, and where upgraded modules read modules defined to class loaders other than the platform class loader and its ancestors, then the platform class loader may have to delegate to other class loaders, the application class loader for example. In other words, classes in named modules defined to class loaders other than the platform class loader and its ancestors may be visible to the platform class loader.

• System class loader: It is also known as application class loader and is distinct from the platform class loader. The system class loader is typically used to define classes on the application class path, module path, and JDK-specific tools. The platform class loader is a parent or an ancestor of the system class loader that all platform classes are visible to it.