上QQ阅读APP看书，第一时间看更新
Reviewing Java's platform module system [JEP-200]
The core aim of JEP-200 was to modularize the Java Development Kit (JDK) using the Java Platform Module System (JPMS). Prior to Java 9, our familiarity with the JDK includes awareness of its major components:
- Java runtime environment (JRE)
- The interpreter (java)
- Compiler (javac)
- The archiver (jar)
- 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 | lava.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.util.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.dgc |
| 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 |
| javax.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.naming.ldap | javax.naming.spi | javax.security.auth.kerberos |
| javax.security.sasl | javax.sql.rowset | javax.sql.rowset.serial |
| javax.sql.rowest.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 Java 9. 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-- http://www.jcp.org.
- 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 non-standard 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 non-standard module. While this dependency is permitted, implied readability access to non-standard modules is not.
- The final design principle ensures non-standard modules do not export standard API packages.