How many unnamed modules are created in Java 9?

Question

I am trying to understand how JPMS works.

From here

The class path is not yet complete. All JARs (modular or not) and classes in the classpath will be contained in the "No Name" module. Like automatic modules, it exports all packages and reads all other modules. But he has no name, obviously. For this reason, it cannot be required and read using the named application modules. An unnamed module, in turn, can access all other modules.

Please note ...on the classpath will be contained in the Unnamed Module . The module is singular.

From here

For compatibility, all code in the classpath is packaged as a special unnamed module, without hidden packages and full access to the entire JDK.

unnamed module again. The module is singular.

Do I understand correctly that in JPMS there is always only one unnamed module? Does this mean that applications that were developed prior to Java9 and not updated for Java9 will be downloaded as one unnamed module?

Answer 1

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

In short

Generally speaking, no. But let's say this: if you put some or even all JAR files in the class path, and your application does not create class loaders to load any additional content, then there is only one unnamed module that you need to take care of.

More details

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

As nullpointer's answer explains in detail, the default application will use three separate class loaders. Perhaps he can deploy his own class loaders, for example, to load plugins. However, if this is not the case, all the application code will end up in the bootloader of the system / application class and, therefore, in the same unnamed module. That's why usually only one is needed that you need to take care of.

Does this mean that applications that were developed prior to Java9 and not updated for Java9 will be downloaded as one unnamed module?

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

If it is on the path to the class, it falls into the unnamed module along with other contents of the class path. This is true for simple JARs without a module descriptor, but also for modular JARs that contain one.

If it is on the way to the module, it gets its own module. If it is a modular JAR, it receives an explicit module like the ones described in the entire state of the module system — simple JAR files turn into automatic modules (note the plural: one automatic module per JAR).

Answer 2

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

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

In implementations of the Java SE platform that use a hierarchical file system to store packages, one of the typical strategies is to combine an unnamed package with each directory; only one unnamed package is displayed at a time, namely one that is associated with the "current working directory". The exact meaning of the "current working directory" depends on the host system.

---

Does this mean that applications that were developed prior to Java9 and not updated for Java9 will be downloaded as one unnamed module?

Yes, for those cans placed on the classpath, it will be considered as one unnamed module. Upstream migration with the concept of unnamed modules illustrates this with a similar example:

Suppose, for example, that the application shown above was originally built for Java SE 8, as a collection of JAR files with the same name, placed on the class path. If we run it as it is on Java SE 9, then the types in the JAR files will be defined in an unnamed module.

---

The actual question that may arise here is Which classloader is an unnamed module? The state of a modular system about an unnamed module contains an explanation about this.

Each classloader, it turns out, has its own unique unnamed module, which is returned by the new ClassLoader::getUnnamedModule . If the class loader loads a type that is not defined in the named module, then this type is considered to be an unnamed module in this loader, i.e. The getModule method of the Class objects will return its unnamed module loader. A module, which is called an “unnamed module” in a conversation, it’s just an unnamed application module class loader that loads types from the classpath when they are in packages not defined by any known module.

ClassLoader , as fixed in Java-9, states that:

Java runtime has the following built-in class loaders:

• Bootstrap class loader : built-in virtual machine Bootstrap class loader ...

• Platform class loader : ... In order to ensure that the modules defined on the platform are updated / redefined by the class loader, the modules of the updated modules read modules defined by the class loaders other than the platform class loader and its ancestors, then the platform class loader may need to be delegated to others class loaders, for example, an application class loader. In other words, classes in named modules specific to class loaders other than the platform class the loader and its ancestors can be visible to the platform class loader.

• System class loader . It is also known as the application class loader and is different from the platform class loader. The class loader system is usually used to define classes in an application, the class path, module path, and special JDK tools. The loader platform class is the parent or ancestor of the system class loader that all platform classes are visible to it.