Java 9 Modules

External

• https://www.baeldung.com/java-9-modularity
• https://www.oracle.com/corporate/features/understanding-java-9-modules.html
• https://www.infoq.com/presentations/java-9-modules

Internal

• Java

Concepts

Module

A module is a group of closely related Java packages and resources, shipped together with a module descriptor file module-info.java. A module can be thought of as a package of Java packages. Modules are exposed to the JVM on the modulepath.

Module Types

System Module

A system module is a named module available with the JDK. They can be listed with java --list-modules See List Modules below.

Application Module

Custom modules we usually build. They are named and defined in module-info.java descriptor included in the artifact JAR.

Automatic Module

For JARs created before Java 9, code will get a module name derived from the JAR file name if an existing JAR that was not built as a module is added to modulepath. Automatic modules have full read access to every other module loaded from the modulepath.

Unnamed Module

The "unnamed" module contains code compiled without a module-info.java descriptor and exposed to the JVM on classpath. This is a catch-all module introduced to maintain compatibility with pre-Java 9 artifacts.

Module Descriptor module-info.java

module-info.java is file that represents a module descriptor.

If code is compiled without a module-info.java, the code will be part of the "unnamed" module and can see all other code in the "unnamed", java.base and modules in the java.se root module. That means if no module-info.java is present in the project, everything should still work as in Java 8. Dependencies should be put on the classpath, not on modulepath.

If the code is compiled with a module-info.java, the code will become part of its own named module, and can only see code in java.base and other named modules with are referenced with requires in module-info.java.

Module Descriptor Elements

Module Name

The name of the module. The naming rules are similar to those that apply for packages. Does are allowed, dashes are not.

Dependencies

A list of other modules this module depends on.

Public Packages

A list of packages that will be accessible from the outside the module. If a package is not listed, it is by default private and it will not be accessible from outside the module. The same is true for reflection, reflection cannot be used unless the package is declared as public.

Services Offered

The definition of service implementations that can be consumed by other modules.

Services Consumed

The definition of services the module consumes.

Reflection Permissions

Explicitly allows other classes to use reflection to access private members of a package.

Package

A module package is identical with a regular Java package. While writing a module, code is organized internally in packages just like before Java 9. Packages are used to determine what code is publicly accessible outside the module.

Resource

Each module encapsulates its resources like configuration files and media.

Modulepath

All the code on the modulepath lives in their own "named" modules. Named modules are only found via the modulepath.

The JRE is always on the modulepath, so its internal code cannot be accessed from code on the classpath.

Package Relationship to Modules

A package can only be accessed from one module. Hierarchical packages are treated as separate, so "java.util" and "java.util.logging" can exist in different modules. Only public fields and methods are accessible in the code of exported packages of other modules.

Classpath

All the code from classpath lives together in the "unnamed" module.

Operations

List Modules

java --list-modules

Organizatorium

• Classpath and module path is mutually exclusive.