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. Modules can be distributed as JARs or as "exploded" compiled projects. When distributed as JARs, there could be just one module per JAR file - each module should be bundled as a separate JAR.

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. The system modules are split in at least two major groups: java, which contain the implementation classes for the core SE Language Specification, and jdk, which contains code needed by the JDK.

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.

Example

module my.module {
  // all directives are optional
  requires other.module.a, other.module.b;
}

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. The dependencies are declared using the keyword requires:

module my.module {
  requires other.module.a;
}

requires declares at the same time a compile-time and runtime dependency on the specified modules. All public types exported from a dependency are accessible by the module requiring them.

Compile-time dependencies are created by using the requires static keywords.

module my.module {
  requires static other.module.b;
}

If we want the declared dependencies to bring in transitively their dependencies, use requires transitive keywords:

module my.module {
  requires transitive other.module.c;
}

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.

TODO exports:

• https://www.baeldung.com/java-9-modularity#4-exports
• https://www.baeldung.com/java-9-modularity#5-exports--to

Services Offered

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

TODO provides ... with :

• https://www.baeldung.com/java-9-modularity#7-provides--with

Services Consumed

The definition of services the module consumes.

TODO uses:

• https://www.baeldung.com/java-9-modularity#6-uses

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.

Modules and Reflection

TODO open, opens, opens ... to:

• https://www.baeldung.com/java-9-modularity#8-open
• https://www.baeldung.com/java-9-modularity#9-opens
• https://www.baeldung.com/java-9-modularity#9-opens
• https://www.baeldung.com/java-9-modularity#visibility

Operations

List Modules

java --list-modules

Organizatorium

• Classpath and module path is mutually exclusive.