Java Platform Module System: Difference between revisions

Content deleted Content added
No edit summary
 
(70 intermediate revisions by 35 users not shown)
Line 1:
{{short description|Distribution format for Java code and resources}}
The '''Java Platform Module System''' specifies a distribution format for collections of [[Java (programming language)|Java]] code and associated resources. It also specifies a repository for storing these collections, or ''[[modular programming|modules]]'', and identifies how they can be discovered, loaded and checked for integrity. It includes features such as versioning and namespaces with the aim of fixing some of the shortcomings in the existing [[JAR (file format)|JAR]] format, especially the [[Java Classloader#JAR hell|JAR Hell]], which can lead to issues such as classpath and class loading problems.
The '''Java Platform Module System'''<ref>{{cite web
| url=http://openjdk.java.net/projects/jigsaw/spec/
| title=Java Platform Module System (JSR 376)
| publisher=[[Oracle Corporation]]
| accessdate=2018-07-02}}</ref> specifies a distribution format for collections of [[Java (programming language)|Java]] code and associated resources. It also specifies a repository for storing these collections, or ''[[modular programming|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 (file format)|JAR]] format, especially the [[Java class loader#JAR hell|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.
Line 7 ⟶ 12:
| title=Project Jigsaw
| publisher=[[Oracle Corporation]]
| accessdate=2015-11-29}}</ref> was created to modularize the JDK.<ref>{{cite webThis JSR was superseded by JSR 376 (Java Platform Module System).
| url=https://blogs.oracle.com/mr/entry/jigsaw
| title=Project Jigsaw
| publisher=[[Oracle Corporation]]
| author=Mark Reinhold
| date=2008-12-02
| accessdate=2015-11-29}}</ref> 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,<ref>{{cite web
| url=http://mreinhold.org/blog/plan-b
| title=It’sIt's time for … Plan B
| publisher=[[Oracle Corporation]]
| author=Mark Reinhold
| date=20082009-1209-0220
| accessdate=20152017-1106-2921}}</ref> and again deferred to a [[Java 9]] release in 2017.<ref>{{cite web
| url=http://openjdk.java.net/projects/jdk9/
| title=JDK 9
| publisher=[[Oracle Corporation]]
| accessdate=2016-02-24}}</ref> Java 9 including the Java Module System was released on September 21, 2017.<ref>{{cite web|url=https://www.techworld.com/news/developers/java-9-release-date-new-features-3660988/|title=Java 9: Release date and new features|publisher=techworld.com|date=2017-07-21|accessdate=2017-11-18}}</ref>
| accessdate=2016-02-240}}</ref> On 2017-05-08 the Java Expert Group voted "No" on JSR 376 further delaying the release of Jigsaw. <ref>{{cite web
| url=https://jcp.org/en/jsr/results?id=5959
| title=JSR #376 Java Platform Module System Public Review Ballot
| publisher=[[Oracle Corporation]]
| accessdate=2016-06-20}}.</ref>
 
== Architecture ==
The Java Module System implemented forin Java 9 will includeincludes the following [[JDK Enhancement Proposal|JEP]]s and [[Java Community Process|JSR (Java Specification Request)]]:<ref name="jigsaw"/>
* JEP 200: The Modular JDK: Define a modular structure for the JDK
* JEP 201: Modular Source Code: Reorganize the JDK source code into modules, enhance the build system to compile modules, and enforce module boundaries at build time
* JEP 220: Modular Run-Time Images: Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability
* JEP 260: Encapsulate Most Internal APIs
* JEP 261: Module System: Implement the Java Platform Module System
* JEP 282: The Java Linker: Create a tool that can assemble and optimize a set of modules and their dependencies into a custom run-time image <ref>{{cite web
| url=http://openjdk.java.net/jeps/282
| title=jlink: The Java Linker (JSR 282)
| publisher=[[Oracle Corporation]]
| accessdate=2016-03-12}}</ref>
* JSR 376: Java Platform Module System <ref>{{cite web
| url=http://openjdk.java.net/projects/jigsaw/spec/
| title=Java Platform Module System (JSR 376)
Line 49 ⟶ 43:
| accessdate=2015-11-29}}</ref>
 
Additionally, several other JDK 9 features have been added to ease transition to the module system:
Modules are a new way of grouping code and data. Contrary to [[JAR (file format)|Jar files]], modules explicitly declare which modules they depend on, and what packages they export.<ref>{{cite web
* JEP 238: Multi-Release JAR Files: Extend the JAR file format to allow multiple, Java-release-specific versions of class files to coexist in a single archive.<ref>{{cite web
| url=http://openjdk.java.net/jeps/238
| title=JEP 238: Multi-Release JAR Files
| publisher=[[Oracle Corporation]]
| accessdate=2017-07-31}}</ref>
* JEP 253: Prepare [[JavaFX]] UI Controls & CSS APIs for Modularization: Define public APIs for the JavaFX functionalities that is presently only available via internal APIs and would become inaccessible due to modularization.<ref>{{cite web
| url=http://openjdk.java.net/jeps/253
| title=JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization
| publisher=[[Oracle Corporation]]
| accessdate=2017-07-31}}</ref>
* JEP 260: Encapsulate Most Internal APIs: Make most of the JDK's internal APIs inaccessible by default but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality.<ref>{{cite web
| url=http://openjdk.java.net/jeps/260
| title=JEP 260: Encapsulate Most Internal APIs
| publisher=[[Oracle Corporation]]
| accessdate=2017-07-31}}</ref>
* JEP 275: Modular Java Application Packaging: The [[Java packager]] will evolve for JDK 9, making it aware of modules, allowing for example to package a module and all the modules it depends on.<ref>{{cite web
| url=http://openjdk.java.net/jeps/275
| title=JEP 275: Modular Java Application Packaging
| publisher=[[Oracle Corporation]]
| accessdate=2017-07-31}}</ref>
 
== Properties of modules ==
 
Modules are used to group packages and tightly control what packages belong to the public API. Contrary to [[JAR (file format)|Jar files]], modules explicitly declare which modules they depend on, and what packages they export.<ref>{{cite web
| url=http://openjdk.java.net/projects/jigsaw/spec/sotms/
| title=The State of the Module System
Line 55 ⟶ 73:
| author=Mark Reinhold
| date=2016-03-08
| accessdate=2017-02-18}}</ref> Explicit dependency declarations improve the integrity of the code, by making it easier to reason about large applications and the dependencies between software components.
| accessdate=2017-02-18}}</ref>
 
The module declaration is placed in a file named {{mono|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'':
 
<pre>
For example, the following module declaration declares that the module {{mono|com.foo.bar}} depends on another {{mono|com.foo.baz}} module, and exports the following packages: {{mono|com.foo.bar.alpha}} and {{mono|com.foo.bar.beta}}:
<syntaxhighlight lang="cpp">
module com.foo.bar {
requires com.foo.baz;
 
exports com.foo.bar.alpha;
exports com.foo.bar.beta;
}
</syntaxhighlight>
</pre>
The public members of {{mono|com.foo.bar.alpha}} and {{mono|com.foo.bar.beta}} packages will be accessible by dependent modules. Private members are inaccessible even through a means such as [[reflective programming|reflection]]. Note that in [[Java version history|Java versions]] 9 through 16, whether such 'illegal access' is ''de facto'' permitted depends on a command line setting.<ref name="JEP 396: Strongly Encapsulate JDK Internals by Default">{{cite web | url=https://openjdk.java.net/jeps/396 | title=JEP 396: Strongly Encapsulate JDK Internals by Default | access-date=2021-02-06}}</ref>
 
Contrary to the Jar file format, the module will describe these dependencies in a module declaration which will be placed in a file named ''module-info.java'' at the root of the module’s source-file hierarchy. The JDK will able to check them both at compile-time and runtime. The JDK itself willhas bebeen modularized forin [[Java version history#Java SE 9|Java 9]].<ref>{{cite web
| url=http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html
| title=JDK Module Summary
| publisher=[[Oracle Corporation]]
| date=2016-06-24
| accessdate=2017-02-18}}</ref>
| archive-date=2015-12-08
| archive-url=https://web.archive.org/web/20151208074800/http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html
| url-status=dead
}}</ref> For example, the majority of the Java standard library is exported by the module <code>java.base</code>.
 
As of Java 25, modules can themselves be imported, automatically importing all exported packages.<ref>{{Cite web|url=https://openjdk.org/jeps/494|title=JEP 494: Module Import Declarations (Second Preview)|website=openjdk.org}}</ref> This is done using <code>import module</code>. For example, <syntaxhighlight lang="Java" inline>import module java.sql;</syntaxhighlight> is equivalent to
<syntaxhighlight lang="Java">
import java.sql.*;
import javax.sql.*;
// Remaining indirect exports from java.logging, java.transaction.xa, and java.xml
</syntaxhighlight>
Similarly, <syntaxhighlight lang="Java" inline>import module java.base;</syntaxhighlight>, similarly, imports all 54 packages belonging to <code>java.base</code>.
 
<syntaxhighlight lang="Java">
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<String> 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()
));
}
}
</syntaxhighlight>
 
Modules use the following [[List of Java keywords|keywords]]:
* <code>exports</code>: used in a module declaration to specify which packages are available to other modules
* <code>module</code>: declares a module
* <code>open</code>: indicates that all classes in a package are accessible via reflection by other modules
* <code>opens</code>: used to open a specific package for reflection to other modules
* <code>provides</code>: used to declare that a module provides an implementation of a service interface
* <code>requires</code>: used in a module declaration to specify that the module depends on another module
* <code>to</code>: used with the <code>opens</code> directive to specify which module is allowed to reflectively access the package
* <code>transitive</code>: used with the <code>requires</code> 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
* <code>uses</code>: used in a module to declare that the module is using a service (i.e. it will consume a service provided by other modules)
* <code>with</code>: used with the <code>provides</code> directive to specify which implementation of a service is provided by the module
 
== Standard modules ==
=== Core modules ===
The modules under namespace <code>java.*</code> belong to the [[Java Platform, Standard Edition]], and modules under namespace <code>jdk.*</code> belong to the [[Java Development Kit]].<ref>{{Cite web|url=https://docs.oracle.com/en/java/javase/24/docs/api/index.html|title=Java® Platform, Standard Edition & Java Development Kit Version 24 API Specification|website=docs.oracle.com}}</ref>
{| class="wikitable"
! Name !! Description
|-
| {{code|java.base}}
| Defines the core APIs that form the foundation of the Java SE Platform.
Implicitly required by all modules and does not need to be declared with <code>requires</code> inside a module declaration.
|-
| {{code|java.compiler}}
| Defines APIs related to the language model, [[Java annotation]] processing, and the [[Java compiler]].
|-
| {{code|java.datatransfer}}
| Defines the APIs that facilitate data transfer between applications or within an application.
|-
| {{code|java.desktop}}
| Defines the [[Abstract Window Toolkit]] (AWT) and [[Swing (Java)|Swing]] libraries for user interfaces, along with APIs for accessibility, audio, imaging, printing, and [[JavaBeans]].
|-
| {{code|java.instrument}}
| Defines services that allow for the instrumentation of programs running on the [[Java Virtual Machine]] (JVM).
|-
| {{code|java.logging}}
| Defines the API for [[Logging (computing)|logging]] events in Java applications (Java Logging API).
|-
| {{code|java.management}}
| Defines the APIs for the [[Java Management Extensions]] (JMX) framework.
|-
| {{code|java.management.rmi}}
| Defines the [[Remote Method Invocation]] (RMI) connector for the Java Management Extensions (JMX) Remote API.
|-
| {{code|java.naming}}
| Defines the API for [[Java Naming and Directory Interface]] (JNDI) services.
|-
| {{code|java.net.http}}
| Defines the API for [[HTTP client]] and [[WebSocket]] functionality.
|-
| {{code|java.prefs}}
| Defines the API for managing and storing user preferences.
|-
| {{code|java.rmi}}
| Defines the Remote Method Invocation (RMI) API for object communication across Java virtual machines.
|-
| {{code|java.scripting}}
| Defines the API for integrating [[scripting engine]]s into Java applications (Scripting API).
|-
| {{code|java.se}}
| Defines the standard API for the Java SE Platform.
|-
| {{code|java.security.jgss}}
| Defines the Java binding for the [[Internet Engineering Task Force|IETF]] [[Generic Security Services Application Programming Interface|Generic Security Services API]] (GSS-API) for security contexts.
|-
| {{code|java.security.sasl}}
| Defines Java's support for the [[Simple Authentication and Security Layer]] (SASL) protocol.
|-
| {{code|java.smartcardio}}
| Defines the API for interacting with [[smart card]] devices (Java Smart Card I/O API).
|-
| {{code|java.sql}}
| Defines the [[Java Database Connectivity]] (JDBC) API for database interaction.
|-
| {{code|java.sql.rowset}}
| Defines the JDBC RowSet API for managing and interacting with tabular data in Java.
|-
| {{code|java.transaction.xa}}
| Defines an API for managing distributed transactions within JDBC.
|-
| {{code|java.xml}}
| Defines the [[Java API for XML Processing]] (JAXP), including tools for parsing and transforming XML data.
|-
| {{code|java.xml.crypto}}
| Defines the API for [[XML Encryption|cryptographic operations]] with XML data.
|-
| {{code|jdk.accessibility}}
| Defines utility classes for implementing [[Assistive technology|Assistive Technologies]] in the JDK.
|-
| {{code|jdk.attach}}
| Defines the attach API for connecting to and interacting with a running JVM instance (attach API).
|-
| {{code|jdk.charsets}}
| Provides additional [[character encoding|character sets]] ({{mono|charset}}s), including double-byte and IBM-specific charsets, not included in <code>java.base</code>.
|-
| {{code|jdk.compiler}}
| Defines the internal implementation of the Java compiler and the command-line tool ''[[javac]]''.
|-
| {{code|jdk.crypto.cryptoki}}
| Defines the implementation of the SunPKCS11 security provider for cryptographic operations.
|-
| {{code|jdk.dynalink}}
| Defines the API for dynamically linking high-level operations on objects.
|-
| {{code|jdk.editpad}}
| Implements the edit pad service used by <code>jdk.jshell</code> for evaluating code.
|-
| {{code|jdk.hotspot.agent}}
| Provides the implementation for the [[HotSpot (virtual machine)|HotSpot]] Serviceability Agent.
|-
| {{code|jdk.httpserver}}
| Defines the JDK-specific HTTP server API and the ''jwebserver'' tool for running a simple HTTP server.
|-
| {{code|jdk.incubator.vector}}
| Defines the API for expressing computations that can be compiled into SIMD instructions at runtime, such as AVX or NEON instructions.
|-
| {{code|jdk.jartool}}
| Provides tools for manipulating [[JAR (file format)|Java Archive]] (JAR) files, such as the ''jar'' and ''jarsigner'' commands.
|-
| {{code|jdk.javadoc}}
| Defines the system documentation tool implementation and its command-line version, ''[[Javadoc|javadoc]]''.
|-
| {{code|jdk.jcmd}}
| Defines tools for diagnosing and troubleshooting JVM processes, including ''jcmd'', ''jps'', and ''jstat''.
|-
| {{code|jdk.jconsole}}
| Defines the JMX-based graphical tool, ''[[JConsole|jconsole]]'', for monitoring and managing Java applications.
|-
| {{code|jdk.jdeps}}
| Defines tools for analysing dependencies in Java programs and libraries, such as ''jdeps'', ''javap'', ''jdeprscan'', and ''jnativescan''.
|-
| {{code|jdk.jdi}}
| Defines the [[Java Platform Debugger Architecture#Java Debugger Interface (JDI)|Java Debug Interface]] (JDI) for debugging Java applications.
|-
| {{code|jdk.jdwp.agent}}
| Provides the implementation of the [[Java Debug Wire Protocol]] (JDWP) agent for remote debugging.
|-
| {{code|jdk.jfr}}
| Defines the API for [[JDK Flight Recorder]] (JFR) for collecting performance and diagnostic data.
|-
| {{code|jdk.jlink}}
| Defines the ''jlink'' tool for creating custom runtime images, and ''jmod'' and ''jimage'' tools for managing JMOD and JDK container files.
|-
| {{code|jdk.jpackage}}
| Defines the [[Java packager]] tool (''jpackage'') for creating platform-specific application packages.
|-
| {{code|jdk.jshell}}
| Provides the ''jshell'' tool for interactively evaluating Java code snippets.
|-
| {{code|jdk.jsobject}}
| Defines the API for integrating [[JavaScript]] objects in Java applications.
|-
| {{code|jdk.jstatd}}
| Defines the ''jstatd'' tool for remotely monitoring JVM statistics.
|-
| {{code|jdk.localedata}}
| Provides locale-specific data for non-US locales.
|-
| {{code|jdk.management}}
| Defines JDK-specific management interfaces for JVM monitoring and control.
|-
| {{code|jdk.management.agent}}
| Defines the JMX-based management agent for the JVM.
|-
| {{code|jdk.management.jfr}}
| Defines the management interface for JDK Flight Recorder (JFR).
|-
| {{code|jdk.naming.dns}}
| Implements the [[Domain Name System|DNS]] Java Naming provider for resolving ___domain names.
|-
| {{code|jdk.naming.rmi}}
| Implements the RMI Java Naming provider for remote method invocation.
|-
| {{code|jdk.net}}
| Defines the JDK-specific API for network programming.
|-
| {{code|jdk.nio.mapmode}}
| Defines specific file mapping modes available in the JDK.
|-
| {{code|jdk.sctp}}
| Provides the API for [[Stream Control Transmission Protocol]] (SCTP) in the JDK.
|-
| {{code|jdk.security.auth}}
| Implements authentication modules and security-related interfaces within the <code>javax.security.auth</code> package (interfaces in <code>javax.security.auth.*</code>).
|-
| {{code|jdk.security.jgss}}
| Defines extensions to the GSS-API and the implementation of the SASL GSSAPI mechanism in the JDK.
|-
| {{code|jdk.xml.dom}}
| Defines the JDK's subset of the [[World Wide Web Consortium]] (W3C) [[Document Object Model]] (DOM) API not covered by Java SE. Exports packages outside of the <code>java</code> namespace (from <code>org.w3c.dom</code>).
|-
| {{code|jdk.zipfs}}
| Provides the implementation for the ZIP file system provider, enabling access to [[ZIP (file format)|ZIP files]] as file systems.
|}
 
[[Jakarta EE]], formerly part of the Java standard library, is not modularised, however build systems can generate automatic modules for it.
 
=== JavaFX modules ===
[[JavaFX]] was previously bundled with the core JDK, until Java 11 when it was split into OpenJFX. JavaFX is split into the following modules.<ref>{{Cite web|url=https://openjfx.io/javadoc/24/|title=Overview (JavaFX)|website=openjfx.io}}</ref>
{| class="wikitable"
! Name !! Description
|-
| {{code|javafx.base}}
| Defines core APIs for the JavaFX UI toolkit (such as APIs for bindings, properties, collections, and events).
|-
| {{code|javafx.controls}}
| Defines the APIs for UI controls, charts, skins in the JavaFX UI toolkit.
|-
| {{code|javafx.fxml}}
| Defines the FXML APIs in the JavaFX UI toolkit.
|-
| {{code|javafx.graphics}}
| Defines scenegraph, animation, geometry, and other related APIs for the JavaFX UI toolkit.
|-
| {{code|javafx.media}}
| Defines media playback and audio content APIs for the JavaFX UI toolkit.
|-
| {{code|javafx.swing}}
| Defines JavaFX/[[Swing (Java)|Swing]] interop support APIs for the JavaFX UI toolkit.
|-
| {{code|javafx.web}}
| Defines WebView APIs for the JavaFX UI toolkit.
|-
| {{code|jdk.jsobject}}
| Defines APIs for [[JavaScript]] objects.
|-
| {{code|jfx.incubator.input}}
| Incubates mechanism for customising JavaFX controls.
|-
| {{code|jfx.incubator.richtext}}
| Incubates RichTextArea control for JavaFX.
|}
 
== Links with OSGi ==
Line 80 ⟶ 368:
| author=Mark Reinhold
| date=2012-08-24
| accessdate=2015-11-29}}</ref> A couple of interesting articles exploring how the Java Module System and OSGi could interoperate were published in 2016. These can be found on InfoQ<ref>{{cite web
| url=https://www.infoq.com/articles/java9-osgi-future-modularity/
| title=Java 9, OSGi and the Future of Modularity
Line 92 ⟶ 380:
== See also ==
* [[Java package]]
* [[Classpath (Java)]]
* [[Java Classloaderclass loader]]
* [[Modules (C++)]]
 
== References ==
Line 106 ⟶ 395:
* [http://openjdk.java.net/projects/jigsaw/spec/issues/ Java Platform Module System: Issue Summary]
 
[[Category:{{Java (software platform]])}}
 
[[Category:Java specification requests]]
[[Category:Modularity]]