The core aim of JEP-200 was to modularize the JDK using the Java Platform Module System (JPMS). Prior to Java 9, our familiarity with the JDK includes awareness of its major components:
- The JRE
- The interpreter (Java)
- The compiler (Javac)
- The archiver (JAR)
- The document generator (Javadoc)
The task of modularizing the JDK was to break it into components that could be combined at compile time or runtime. The modular structure is based on the following modular profiles established as compact profiles in Java 8. Each of the three profiles is detailed in the following tables:
- Compact profile 1:
| java.io | java.lang.annotation | java.lang.invoke |
| java.lang.ref | java.lang.reflect | java.math |
| java.net | java.nio | java.nio.channels |
| java.nio.channels.spi | java.nio.charset | java.nio.charset.spi |
| java.nio.file | java.nio.file.attribute | java.nio.file.spi |
| java.security | java.security.cert | java.security.interfaces |
| java.security.spec | java.text | java.text.spi |
| java.time | java.time.chrono | java.time.format |
| java.time.temporal | java.time.zone | java.util |
| java.util.concurrent | java.util.concurrent.atomic | java.util.concurrent.locks |
| java.util.function | java.util.jar | java.util.logging |
| java.util.regex | java.tuil.spi | java.util.stream |
| java.util.zip | javax.crypto | javax.crypto.interfaces |
| javax.crypto.spec | javax.net | javax.net.ssl |
| javax.script | javax.security.auth | javax.security.auth.callback |
| javax.security.auth.login | javax.security.auth.spi | javax.security.auth.spi |
| javax.security.auth.x500 | javax.security.cert |
- Compact profile 2:
| java.rmi | java.rmi.activation | java.rmi.drc |
| java.rmi.registry | java.rmi.server | java.sql |
| javax.rmi.ssl | javax.sql | javax.transaction |
| javax.transaction.xa | javax.xml | javax.xml.database |
| javax.xml.namespace | javax.xml.parsers | javax.xml.stream |
| javax.xml.stream.events | javax.xml.stream.util | javax.xml.transform |
| javax.xml.transform.dom | javax.xml.transform.sax | javax.xml.transform.stax |
| java.xml.transform.stream | javax.xml.validation | javax.xml.xpath |
| org.w3c.dom | org.w3c.dom.bootstrap | org.w3c.dom.events |
| org.w3c.dom.ls | org.xml.sax | org.xml.sax.ext |
| org.xml.sax.helpers |
- Compact profile 3:
| java.lang.instrument | java.lang.management | java.security.acl |
| java.util.prefs | javax.annotation.processing | javax.lang.model |
| javax.lang.model.element | javax.lang.model.type | javax.lang.model.util |
| javax.management | javax.management.loading | javax.management.modelmbean |
| javax.management.monitor | javax.management.openmbean | javax.management.relation |
| javax.management.remote | javax.management.remote.rmi | javax.management.timer |
| javax.naming | javax.naming.directory | javax.naming.event |
| javax.naing.ldap | javax.naming.spi | javax.security.auth.kerberos |
| javax.security.sasl | javax.sql.rowset | javax.sql.rowset.serial |
| javax.sql.rowset.spi | javax.tools | javax.xml.crypto |
| javax.xml.crypto.dom | javax.xml.crypto.dsig | javax.xml.crypto.dsig.dom |
| javax.xml.crypto.dsig.keyinfo | javax.xml.crypto.dsig.spec | org.ieft.jgss |
The three compact module profiles represent the basis for the standardized modular system in the current Java platform. The effectiveness of this standardization relies on the following six principles:
- All JCP-governed modules must start with the string java. So, if a module on spatial utilities was being developed, it would have a name such as java.spatial.util.
JCP refers to the Java Community Process. JCP allows developers to create technical specifications for Java. You can learn more about JCP and become a member at the official JCP website at https://www.jcp.org/en/home/index.
- Non-JCP modules are considered part of the JDK and their names must start with the string jdk.
- Ensure method invocation chaining works properly. This is best illustrated with the following flowchart:
As you can see in the preceding flowchart, it only applies to modules that export a package.
- The fourth principle deals with both standard and nonstandard API packages being used in a standard module. The following flowchart illustrates the implementation of this principle's covenants:
- The fifth design principle is that standard modules can be dependent upon more than one nonstandard module. While this dependency is permitted, implied readability access to nonstandard modules is not.
- The final design principle ensures nonstandard modules do not export standard API packages.