Java Platform Module System

The Java Platform Module System (JPMS) specifies a distribution format for collections of Java code and associated resources. It also specifies a repository for storing these collections, or modules, and identifies how they can be discovered, loaded and checked for integrity. It includes features such as namespaces with the aim of fixing some of the shortcomings in the existing JAR format, especially the JAR Hell, which can lead to issues such as classpath and class loading problems. The Java Module System was initially being developed under the Java Community Process as JSR 277 and was scheduled to be released with Java 7. JSR 277 later was put on hold and Project Jigsaw was created to modularize the JDK. This JSR was superseded by JSR 376 (Java Platform Module System). Project Jigsaw was originally intended for Java 7 (2011) but was deferred to Java 8 (2014) as part of Plan B, and again deferred to a Java 9 release in 2017. Java 9 including the Java Module System was released on September 21, 2017.

The Java Platform Module System (JPMS) specifies a distribution format for collections of Java code and associated resources. It also specifies a repository for storing these collections, or modules, and identifies how they can be discovered, loaded and checked for integrity. It includes features such as namespaces with the aim of fixing some of the shortcomings in the existing JAR format, especially the JAR Hell, which can lead to issues such as classpath and class loading problems. The Java Module System was initially being developed under the Java Community Process as JSR 277 and was scheduled to be released with Java 7. JSR 277 later was put on hold and Project Jigsaw was created to modularize the JDK. This JSR was superseded by JSR 376 (Java Platform Module System). Project Jigsaw was originally intended for Java 7 (2011) but was deferred to Java 8 (2014) as part of Plan B, and again deferred to a Java 9 release in 2017. Java 9 including the Java Module System was released on September 21, 2017. module org.wikipedia.bar { requires org.wikipedia.baz; exports org.wikipedia.bar.alpha; exports org.wikipedia.bar.beta; } The public members of org.wikipedia.bar.alpha and org.wikipedia.bar.beta packages will be accessible by dependent modules. Private members are inaccessible even through a means such as reflection. Note that in Java versions 9 through 16, whether such 'illegal access' is de facto permitted depends on a command line setting. The JDK itself has been modularized in Java 9. For example, the majority of the Java standard library is exported by the module java.base . As of Java 25, modules can themselves be imported, automatically importing all exported packages. This is done using import module . For example, import module java.sql; is equivalent to import java.sql.*; import javax.sql.*; // Remaining indirect exports from java.logging, java.transaction.xa, and java.xml Similarly, import module java.base; , similarly, imports all 54 packages belonging to java.base . package org.wikipedia.examples; import module java.base; /** * Importing module java.base allows us to avoid manually importing most classes * The following classes (outside of java.lang) are used: * - java.text.MessageFormat * - java.util.Date * - java.util.List * - java.util.concurrent.ThreadLocalRandom */ public class Example { public static void main(String[] args) { List colours = List.of("Red", "Orange", "Yellow", "Green", "Blue", "Indigo", "Violet"); IO.println(MessageFormat.format("My favourite colour is {0} and today is {1,date,long}", colours.get(ThreadLocalRandom.current().nextInt(colours.size())), new Date() )); } } Modules use the following keywords: exports : used in a module declaration to specify which packages are available to other modules module : declares a module open : indicates that all classes in a package are accessible via reflection by other modules opens : used to open a specific package for reflection to other modules provides : used to declare that a module provides an implementation of a service interface requires : used in a module declaration to specify that the module depends on another module to : used with the opens directive to specify which module is allowed to reflectively access the package transitive : used with the requires directive to indicate that a module not only requires another module but also makes that module's dependencies available to modules that depend on it uses : used in a module to declare that the module is using a service (i.e. it will consume a service provided by other modules) with : used with the provides directive to specify which implementation of a service is provided by the module module jdk.unsupported { exports sun.misc; exports sun.reflect; exports com.sun.nio.file; opens sun.misc; opens sun.reflect; } Jakarta EE, formerly part of the Java standard library, is not modularised, however build systems can generate automatic modules for it. JSR 277 JSR 294 JSR 376 Project Jigsaw The State of the Module System Java Platform Module System: Issue Summary

Text derived from https://en.wikipedia.org/w/index.php?oldid=1372081246 under CC BY-SA 4.0; modifications have been made.