Here’s a cool Java 9 feature — Automatic-Module-Name

Automatic-Module-Name:

ModuleFinder -

A finder of modules. A ModuleFinder is used to find modules during resolution or service binding.

A ModuleFinder can only find one module with a given name. A ModuleFinder that finds modules in a sequence of directories, for example, will locate the first occurrence of a module of a given name and will ignore other modules of that name that appear in directories later in the sequence.

Example usage:

Path dir1, dir2, dir3;
     ModuleFinder finder = ModuleFinder.of(dir1, dir2, dir3);
     Optional<ModuleReference> omref = finder.find("jdk.foo");
     omref.ifPresent(mref -> ... );

The find and findAll methods defined here can fail for several reasons. These include I/O errors, errors detected parsing a module descriptor (module-info.class), or in the case of ModuleFinder returned by ModuleFinder.of, that two or more modules with the same name are found in a directory. When an error is detected then these methods throw FindException with an appropriate cause. The behavior of a ModuleFinder after a FindException is thrown is undefined. For example, invoking find after an exception is thrown may or may not scan the same modules that lead to the exception. It is recommended that a module finder be discarded after an exception is thrown.

A ModuleFinder is not required to be thread safe.

—

Returns a module finder that locates modules on the file system by searching a sequence of directories and/or packaged modules. Each element in the given array is one of:

1. A path to a directory of modules.
2. A path to the top-level directory of an exploded module.
3. A path to a packaged module.

The module finder locates modules by searching each directory, exploded module, or packaged module in array index order. It finds the first occurrence of a module with a given name and ignores other modules of that name that appear later in the sequence.

If an element is a path to a directory of modules then each entry in the directory is a packaged module or the top-level directory of an exploded module. It is an error if a directory contains more than one module with the same name. If an element is a path to a directory, and that directory contains a file named module-info.class, then the directory is treated as an exploded module rather than a directory of modules.

The module finder returned by this method supports modules packaged as JAR files. A JAR file with a module-info.class in its top-level directory, or in a versioned entry in a multi-release JAR file, is a modular JAR file and thus defines an explicit module. A JAR file that does not have a module-info.class in its top-level directory defines an automatic module, as follows:

• If the JAR file has the attribute “Automatic-Module-Name" in its main manifest then its value is the module name. The module name is otherwise derived from the name of the JAR file.
• The version, and the module name when the attribute "Automatic-Module-Name" is not present, are derived from the file name of the JAR file as follows:
• The “.jar" suffix is removed.
• If the name matches the regular expression "-(\\d+(\\.|$))" then the module name will be derived from the subsequence preceding the hyphen of the first occurrence. The subsequence after the hyphen is parsed as a Version and ignored if it cannot be parsed as a Version.
• All non-alphanumeric characters ([^A-Za-z0-9]) in the module name are replaced with a dot ("."), all repeating dots are replaced with one dot, and all leading and trailing dots are removed.
• As an example, a JAR file named “foo-bar.jar" will derive a module name "foo.bar" and no version. A JAR file named "foo-bar-1.2.3-SNAPSHOT.jar" will derive a module name "foo.bar" and "1.2.3-SNAPSHOT" as the version.
• The set of packages in the module is derived from the non-directory entries in the JAR file that have names ending in “.class". A candidate package name is derived from the name using the characters up to, but not including, the last forward slash. All remaining forward slashes are replaced with dot ("."). If the resulting string is a legal package name then it is assumed to be a package name. For example, if the JAR file contains the entry "p/q/Foo.class" then the package name derived is "p.q".
• The contents of entries starting with META-INF/services/ are assumed to be service configuration files (see ServiceLoader). If the name of a file (that follows META-INF/services/) is a legal class name then it is assumed to be the fully-qualified class name of a service type. The entries in the file are assumed to be the fully-qualified class names of provider classes.
• If the JAR file has a Main-Class attribute in its main manifest, its value is a legal class name, and its package is in the set of packages derived for the module, then the value is the module main class.

If a ModuleDescriptor cannot be created (by means of the ModuleDescriptor.Builder API) for an automatic module then FindException is thrown. This can arise when the value of the "Automatic-Module-Name" attribute is not a legal module name, a legal module name cannot be derived from the file name of the JAR file, where the JAR file contains a .class in the top-level directory of the JAR file, where an entry in a service configuration file is not a legal class name or its package name is not in the set of packages derived for the module.

In addition to JAR files, an implementation may also support modules that are packaged in other implementation specific module formats. If an element in the array specified to this method is a path to a directory of modules then entries in the directory that not recognized as modules are ignored. If an element in the array is a path to a packaged module that is not recognized then a FindException is thrown when the file is encountered. Paths to files that do not exist are always ignored.

As with automatic modules, the contents of a packaged or exploded module may need to be scanned in order to determine the packages in the module. Whether hidden files are ignored or not is implementation specific and therefore not specified. If a .class file (other than module-info.class) is found in the top-level directory then it is assumed to be a class in the unnamed package and so FindException is thrown.

Finders created by this method are lazy and do not eagerly check that the given file paths are directories or packaged modules. Consequently, the find or findAllmethods will only fail if invoking these methods results in searching a directory or packaged module and an error is encountered.

—

Creating modular applications using the Java module system is an enticing prospect. Modules have module descriptors in the form of module-info.java, declaring which packages are exported and what dependencies it has on other modules. This means we finally have explicit dependencies between modules at the language level, and can strongly encapsulate code within these modules.

What You Need To Do Now

We need Java library maintainers to step up! Ultimately, it would be best for your library to have a module descriptor so that modular applications can depend on it. Getting there isn’t trivial in all cases. Fortunately, support for the Java module system can be incrementally added to libraries. This post explains the first step you can take as library maintainer on your way to becoming a Java module. This first step boils down to picking a module name, and adding it as Automatic-Module-Name: <module name> entry to the library's MANIFEST.MF. That's it.

With this first step you make your library usable as Java module without moving the library itself to Java 9 or creating a module descriptor for the library, yet. It doesn’t even require re-compilation.

Automatic Modules

Traditional applications are packaged into JARs and run from the classpath. Java 9 still supports this, but also opens the door to more reliable and efficient deployment. Modular applications on Java 9 and later are packaged into JARs which contain module descriptors (modular JARs) and run from the module path. Code in modular JARs on the module path can’t access code in traditional JARs on the classpath. So what happens when a modular application wants to use a library living on the classpath, which doesn’t have a module descriptor yet? The modular application can’t express such a dependency in its module descriptor.

Most likely your library is built using Maven or Gradle. Adding a manifest entry to the resulting JAR is a breeze in both build tools. For Maven, make sure the jar plugin has the following configuration:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jar-plugin</artifactId>
  <configuration>
    <archive>
      <manifestEntries>
        <Automatic-Module-Name>com.acme.mylibrary</Automatic-Module-Name>
      </manifestEntries>
    </archive>
  </configuration>
</plugin>

With Gradle, you can configure the jar plugin as follows:

jar {
    manifest {
        name = "mylibrary"
        instruction "Automatic-Module-Name", "com.acme.mylibrary"
    }
}

—