Modules   «Prev  Next»

Describing Modular Java Development Kit

History of Jars prior to Java 9

Before Java 9 the Java development kit was a monolithic set of packages, packaged in one jar file the rt.jar which any Java application would need to deploy along with its own code.
  1. The Java platform had Grown overtime to include about 25 different frameworks.
  2. Even if your application only ever used one class in a package, you would need the rt.jar which included all of these frameworks.
  3. Project jigsaw was the name of the project created to modularize the JDK

Goals of modularizing the Java Development Kit

The goals of modularizing the Java development kit were summarized by the Project Jigsaw Team and restated here:
  1. more scalability by allowing the Java development kit to more easily scale down to smaller platforms
  2. Improve security by protecting the internals of the Java development kit
  3. Improved maintainability by publishing dependencies and reducing the amount of interdependencies
  4. Improved application performance by allowing configuration flexibility
  5. Easier construction of and maintenance of libraries in large applications

The Java designers spent a lot of time deconstructing the monolith, decoupling the frameworks and reconstructing the code into smaller sets of code (a few dozen modules) that met the 5 objectives outlined above. The smaller sets of code, nicely packaged into modular jar files, comprise the modular JDK.


Java Docs API

Modular Java Development Kit – Java Standard Edition

The Modular Java Development kit is split into two sections. The Java SE, the Java Platform standard edition (Java SE) APIs These API's define the core Java platform for general purpose computing. These API's are in modules whose names start with a Java prefix.

1. All of the modules in the Java (SE) are standard modules as defined by the Java community process JCP However not all standard modules defined by the Java community process are in the Java SE, just the foundational standard modules 2. A standard module may contain both standard and non-standard API packages 3. A standard package is prefixed with java. or javax. such as 1) java.lang or 2) javax.net for example
The second section in the modular JDK 1) The JDK - The Java development kit JDK APIs are specific to the JDK
  1. These API's may not necessarily be available in all implementations of the Java SE platform
  2. These API's are in modules whose names start with a jdk. prefix
  3. These are non-standard modules
  4. A non standard module must not export any standard API packages.
  5. A non standard package is generally prefixed with jdk. such as / jdk.internal.logger for example

1. The following diagram is the module graph, of the modular SE modules (which is part of the Modular Java development kit) 2. A module graph is a diagram, which attempts to visualize the module dependencies of a particular module.
Module Diagram
Module Diagram

In the diagram above the Java.se module has dependencies on all of the modules shown, whereas java.base has no dependencies but is the required dependency for all the modules shown The arrows are called read edges, read because the module is said to be able to “read” another if properly configured as dependent on it. For example, the java.xml module is said to read the java.base module . Note that a module graph only displays module dependencies, and will not include packages.
Module Summary
Each module shown is part of the Java API specification This Link gives you all the information with respect to the java.base module

Providers:

The JDK implementation of this module provides an implementation of the jrt file system provider to enumerate and read the class and resource files in a run-time image. The jrt file system can be created by calling FileSystems.newFileSystem(URI.create("jrt:/")).
The Java dot based module is described as the foundational APIs of the Java SE platform, which include the core packages such as 1) java.lang, 2) java.util, 3) java.io