> ## Documentation Index > Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt > Use this file to discover all available pages before exploring further. # Java Module Declaration A Java module declaration is a configuration file named `module-info.java` located at the root of a module's source hierarchy. It defines the module's name, its dependencies, the packages it exposes, and its service configuration. Upon compilation, it produces a `module-info.class` file that the Java Platform Module System (JPMS) uses to enforce strong encapsulation and reliable configuration at both compile-time and run-time. ## Syntax Anatomy The declaration begins with the `module` keyword (optionally preceded by the `open` modifier), followed by a unique module name, and a block containing specific module directives. ```java theme={"dark"} module com.example.core { // Dependency Directives requires java.logging; requires transitive java.xml; requires static java.compiler; // Encapsulation Directives exports com.example.core.api; exports com.example.core.internal to com.example.specific.module; opens com.example.core.models; opens com.example.core.config to com.example.framework; // Service Directives uses com.example.core.spi.DataService; provides com.example.core.spi.DataService with com.example.core.impl.DataServiceImpl; } ``` ## Module Directives ### 1. `requires` Specifies that this module depends on another module. The JPMS ensures the required module is present in the module path. * **`requires transitive`**: Implies readability. Any module that requires this module will automatically be granted read access to the transitive dependency. * **`requires static`**: Declares a compile-time-only dependency. The module is required for compilation but is optional at run-time. ### 2. `exports` Makes the `public` types (and their `public` and `protected` members or nested types) within the specified package accessible to other modules. Types in unexported packages remain strongly encapsulated and are inaccessible from outside the module, even via reflection. * **Qualified Export (`exports ... to`)**: Restricts the visibility of the exported package to a specific, comma-separated list of target modules. ### 3. `opens` Grants run-time-only access to a package, allowing other modules to use deep reflection (via `setAccessible(true)`) to access `private` and `package-private` members. It does not grant compile-time access. * **Qualified Open (`opens ... to`)**: Restricts deep reflection access to a specific list of target modules. ### 4. `uses` Declares that the module consumes a specific service. It instructs the JPMS that the module will use `java.util.ServiceLoader` to locate and load implementations of the specified service type at run-time. In the JPMS, a service type can be an interface, an abstract class, or a concrete class. ### 5. `provides ... with` Declares that the module provides one or more implementations for a specific service type. The provider class specified after `with` typically implements or extends the service type. However, the provider class does not need to implement or extend the service type if it declares a `public static provider()` method that returns an instance of the service. ## The `open` Module Modifier If a module is declared with the `open` modifier (e.g., `open module com.example.app { ... }`), all packages within the module are implicitly opened for deep reflection at run-time to all other modules. An `open` module cannot contain explicit `opens` directives, as all packages are already open. It can still use `exports` to define its compile-time public API.
Tired of Poor Java Skills? Fix That With Deep Grasping! Learn More