Java 9 introduced significant changes to how classes and resources are loaded. The introduction of the Java Platform Module System (JPMS) altered the way applications handle modules, components, and their dependencies. This article delves into these changes and provides insights into loading classes and resources in a post-Java 9 world.

The Module System

Java 9's module system is the most critical shift in the Java ecosystem. Prior to Java 9, Java applications were mainly composed of JAR files handled via the classpath, which led to challenges like "classpath hell." The module system addresses this by enabling developers to define modules, which are bundles of packages with a well-defined interface (via `module-info.java`). This structure allows greater encapsulation and dependency control.

Key Components of the Module System

• Module Descriptor: Found in the `module-info.java` file, it specifies module dependencies and packages to be exported.
• Module Path: Similar to the classpath, the module path is where the Java runtime searches for module definitions.
• Module Layer: This is the hierarchical layer representing a collection of loaded modules. By default, the Java application module system includes a boot layer.

Class Loading in the Module System

Loading classes in the module system involves understanding these hierarchical structures:

1. Loading Modules:
   • Modules are loaded from the module path rather than JAR files.
   • The Module Layer takes care of creating a consistent and isolated model for resolving and managing dependencies.
2. Class Loaders:
   • Java 9 retains three primary class loaders: Bootstrap ClassLoader, Application ClassLoader, and Platform ClassLoader.
   • Application modules are typically loaded by the Application ClassLoader.
   • The Platform ClassLoader loads Java SE and JDK-specific modules.

Example: Defining and Accessing a Module

Consider building a module named `com.example.mymodule`:

• Package Encapsulation: Non-exported packages cannot have their resources accessed from outside.
• Module Resource URL: Access resource URLs using the `Module` API, e.g., `Module.getResourceAsStream("/my/resource.txt")`.
• Automatic Modules: Existing JARs without a module descriptor can be converted to automatic modules and placed on the module path.
• Unnamed Module: Legacy code using the classpath belongs to the unnamed module, which bridges classpath and module path.
• Split Packages: Previously allowed but now discouraged. Refactor to avoid using the same package in multiple modules.
• Transitive Dependencies: Use the `requires transitive` construct to expose dependencies automatically required by other modules.