Java Platform Module System

1

The Java Platform Module System 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.

Architecture

The Java Module System implemented in Java 9 includes the following JEPs and JSR (Java Specification Request): Additionally, several other JDK 9 features have been added to ease transition to the module system:

Properties of modules

Modules are a new way of grouping code. Contrary to Jar files, modules explicitly declare which modules they depend on, and what packages they export. Explicit dependency declarations improve the integrity of the code, by making it easier to reason about large applications and the dependencies between software components. The module declaration is placed in a file named module-info.java at the root of the module’s source-file hierarchy. The JDK will verify dependencies and interactions between modules both at compile-time and runtime. For example, the following module declaration declares that the module com.foo.bar depends on another com.foo.baz module, and exports the following packages: com.foo.bar.alpha and com.foo.bar.beta: module com.foo.bar { requires com.foo.baz; exports com.foo.bar.alpha; exports com.foo.bar.beta; } The public members of com.foo.bar.alpha and com.foo.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.

Links with OSGi

The Java Module System does not intend to support all the functionalities that the OSGi platform currently supports (for example the Life-Cycle model and the Services Registry). However the Java Module System will support functions which are not supported by OSGi, such as modularity at compile-time, and built-in support for native libraries. A couple of articles exploring how the Java Module System and OSGi could interoperate were published in 2016. These can be found on InfoQ and also the OSGi Alliance Blog.

This article is derived from Wikipedia and licensed under CC BY-SA 4.0. View the original article.

Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc.
Bliptext is not affiliated with or endorsed by Wikipedia or the Wikimedia Foundation.

View original