The Java Platform Module System (JPMS) was introduced in Java 9. It allows you to organize your code by grouping a set of related packages into higher-level components called modules, and provides a mechanism to declare dependencies between modules.

Modularizing your application offers several benefits:

 - An application whose code is organized into modules is easier to read, easier to maintain, and more scalable.

 - Dependencies between modules are defined via module descriptors that are both checked at compile time and when the application is launched. This early resolution of dependencies helps improve runtime reliability, overcoming a long-standing issue in Java where "NoClassDefFoundError" exceptions were common causes of application crashes.

 - The packages in a module are accessible to other modules only if they are explicitly exported. This principle, called strong encapsulation, provides by default a secure space for the code into which reflection cannot intrude.

 - Finally, the module system allows you to create custom runtime images containing only the modules used by your application. The reduced sized of the runtime environment noticeably improves the startup time and memory footprint of the application.

Starting from version 3.5.55, the wrapper.jar file contains a module descriptor which introduces the 'org.tanukisoftware.wrapper' module. This named module can be included in custom runtime images created with jlink.

The Wrapper provides several properties to help you configure how modules are used by your application:

• wrapper.java.module_path.<n>
• wrapper.java.module_path.missing.loglevel
• wrapper.java.upgrade_module_path.<n>
• wrapper.java.upgrade_module_path.missing.loglevel
• wrapper.java.module.<n>

Compatibility :	3.5.55, Requires Java 9+
Editions :
Platforms :

These properties are used to list locations where modules of your application can be found. The list can contain directories, or paths to jar files optionally containing wildcards in the filename portion.

The Wrapper will use this list to build the '--module-path' option of the Java command line.

If a wildcard character is used within a modulepath entry, all matching files will be added to the modulepath used when launching a JVM instance.

Valid wildcard characters are:

• A '*' character, which will match "0" (zero) or more characters.
• A '?' character, which will match exactly one character.

wrapper.java.module_path.1=../lib/myapp-*.jar  # jar files specified with a wildcard
wrapper.java.module_path.2=../lib/tools.jar    # single jar file specified using the exact name
wrapper.java.module_path.3=../lib/ext          # folder where additional modules can be found

Classpath:

Java does not allow two distinct jar files containing the same package to co-exist in the modulepath list. This is not the case with classpath, where historically package overlapping has always been allowed. This is one of the reasons why classpath remains useful, at least until an application can be fully migrated to the Java 9 module system.

Please be aware of the following limitation: jar files listed in the classpath that cannot be found in any locations of the modulepath will be used by the JVM as an unnamed module, which by nature makes it inaccessible to any other modules. If a module is supposed to be referenced in a requires directive of another module, it must exist in one of the locations specified by the wrapper.java.module_path.<n> or wrapper.java.upgrade_module_path.<n> properties.

Problems?

If you encounter any problems related to modulepath, the first thing that should be done is to verify the full modulepath being generated by the Wrapper. To do this, either enable debug log output with the wrapper.debug property, or enable the display of the Java command using the wrapper.java.command.loglevel property.

Compatibility :	3.5.55, Requires Java 9+
Editions :
Platforms :

By default, the Wrapper will log warnings about any missing Module Path elements at the DEBUG log level. It is fairly common to want to see these generated log messages without also enabling all of the debug output. This property makes it possible to specify the log level at which the warnings will be logged.

• FATAL :
  to log at the FATAL log level.
• ERROR :
  to log at the ERROR log level.
• WARN :
  to log at the WARN log level.
• STATUS :
  to log at the STATUS log level.
• INFO :
  to log at the INFO log level.
• DEBUG :
  to log at the DEBUG log level.
• NONE :
  to never log.

The default value is DEBUG.

wrapper.java.module_path.missing.loglevel=DEBUG

If your application often has missing jars, then setting this value to NONE will disable warnings at any log level.

Module Path elements which are defined as wildcards will also log a warning if the wildcard fails to match at least one file. This can happen if the directory is missing or empty.

Compatibility :	3.5.55, Requires Java 9+
Editions :
Platforms :

These properties define a list which is similar to wrapper.java.module_path.<n>, but allow overriding upgradeable modules contained in the runtime image.

Just like for wrapper.java.module_path.<n>, the list can contain directories, or paths to jar files optionally containing wildcards in the filename portion. For more details on the syntax, please refer to the above section.

The Wrapper will use this list to build the '--upgrade-module-path' option of the Java command line.

Compatibility :	3.5.55, Requires Java 9+
Editions :
Platforms :

By default, the Wrapper will log warnings about any missing Upgrade Module Path elements at the DEBUG log level. It is fairly common to want to see these generated log messages without also enabling all of the debug output. This property makes it possible to specify the log level at which the warnings will be logged.

• FATAL :
  to log at the FATAL log level.
• ERROR :
  to log at the ERROR log level.
• WARN :
  to log at the WARN log level.
• STATUS :
  to log at the STATUS log level.
• INFO :
  to log at the INFO log level.
• DEBUG :
  to log at the DEBUG log level.
• NONE :
  to never log.

The default value is DEBUG.

wrapper.java.upgrade_module_path.missing.loglevel=DEBUG

If your application often has missing jars, then setting this value to NONE will disable warnings at any log level.

Upgrade Module Path elements which are defined as wildcards will also log a warning if the wildcard fails to match at least one file. This can happen if the directory is missing or empty.

Compatibility :	3.5.55, Requires Java 9+
Editions :
Platforms :

These properties are used to list the names of the root modules used by your application. Root modules are modules that cannot be pulled in the module graph when the application is launched, either because they are not required by any other modules, or because they are optional dependencies (i.e. specified with 'requires static' in a module descriptor).

The Wrapper will use this list to build the '--add-modules' option of the Java command line.

In addition to module names, the list can include the following tokens:

• ALL-DEFAULT: Adds the default set of root modules for the unnamed module (when the main class is loaded from the class path).

• ALL-SYSTEM: Adds all system modules (this will cause many modules to be resolved, in general ALL-DEFAULT is preferred).

• ALL-MODULE-PATH: Adds all modules on the module path.

Please see the OpenJDK specification for a more detailed description.