The module is a collection of packages designed for reuse, and Module JAR is a regular JAR with a module descriptor in its root folder. An Automatic Module is a JAR from the classpath that has been put in the module path. Their name is derived from the jar file name by default.
Hence there are enormous numbers of pre-existing libraries that you can use in your applications. Many of these are not yet modularized, but to facilitate migration, you can add any library’s JAR file to an app’s module path then use the packages in that JAR. When you do so, the JAR file implicitly becomes an automatic module and specifies the module declaration requires a directive.
It exports all packages, so any module that can read automatic modules has access to all the public types in automatic module’s packages. Reads or requires all other modules, so an automatic module has access to all the public types exposed by the system’s other module
Naming of the Automatic Modules
- If the name follows the regular expression “-(\\d+(\\.|$))” then the module name will be derived from the subsequence preceding the hyphen of the first occurrence.
- The “.jar” suffix or extension is removed.
- All Non-alphanumeric characters [^A-Za-z0-9] in the module name are replaced with a dot “.” ,
- All the repeating dots are replaced by only one dot, “.”, and all leading and trailing dots are removed.
Resources in Automatic Modules
When the automatic module requires resources, such as audios, images, videos, and more, that resources should be packaged with the module to ensure that they’re available when the module’s types are used at execution time.
By convention, resources typically are placed in a folder named res under the module root directory along with the module-info.java file, and this is known as resource encapsulation (shown below).
Uses of Automatic Modules:
- Automatic modules allow you to treat an artifact if it has the attribute Automatic-Module-Name in its main manifest entry.
- Traditional levels of encapsulation, like all packages, are both open for deep reflective access and exported for ordinary compile-time and run-time access to their public types.
- We can read every other named module, whether automatic or explicit.
- We can use it to find errors sooner because that was possible with the classpath.
- Automatic modules make our app lightweight and improve the performance of an app also. By this, it can be run on more devices.
- It helps us develop a modular application or modularize our existing applications without waiting for third-party libraries to become modularized.
Example:
simple-add/src/simple/add/calculate.java
Java
// Java program to define the sum() // method inside the calculate class package simple.add public class calculate { public static int sum(int a1, int a2) { return a1 + a2; }} |
The above example has a class named Calculate, which has a function (sum) to return the addition of two digits.
add.app/src/com/example/main.java
Java
// Java program to import and use the // methods of the calculate class package com.example import simple.add.calculate; public class main { public static void main(String[] args) { int sum = calculate.sum(10, 7); System.out.println("sum is " + sum); }} |
The above code has a main class and uses the function sum of Calculate class by importing them.
add.app/src/module-info.java
module add.app {
requires simple.add;
}
The above module declaration requires the dependency jar module (automatic) by its name, which will transform from “easy-math.jar” to “easy.math”
Output: Below is desired output of the above code by using the automatic module
E:\automatic-module-example\add.app>java --module-path out;lib --module add.app/com.example.main sum : 17
Why Automatic modules?
The Automatic module was introduced to make compiling and initiating applications more smoothly and reliable and to find bugs or errors sooner than was possible with the classpath. To keep them smoothly, there is no way for a module declaration to require anything other than a named module, which excludes everything loaded from the classpath. If the story ended here, a module JAR only relies on other modules JAR, which would penetrate the environment to modularize from the bottom up.
