Java Platform Module System

Java Platform Module System
Name	Java Platform Module System
Other names	JPMS, Project Jigsaw
Developer	Oracle Corporation
Released	2017
Programming language	Java
Operating system	Cross-platform
License	GNU General Public License

Java Platform Module System is a module system introduced in Java SE 9 that reorganizes the Java platform into a set of explicit modules and provides strong encapsulation, configurable runtime images, and improved dependency management. It was developed as part of Project Jigsaw and delivered by Oracle Corporation to address long-standing issues in the Java SE ecosystem, interoperability with OSGi, and to enable scalable deployment in environments such as Android (operating system)-adjacent development and cloud platforms. JPMS affects tools including javac, jdeps, and jlink, and has influenced build systems like Maven (software), Gradle (software), and Ant (software).

Overview

JPMS partitions code into named modules that declare their dependencies and exported APIs, aiming to replace classpath-based composition techniques used since JDK 1.0. The system introduces a module graph akin to dependency graphs used in Apache Maven and features runtime image customization similar to techniques used in Docker containers and Linux distribution packaging. Its introduction sparked comparison with established modular systems like OSGi and generated extensive discussion among contributors from OpenJDK, Oracle Labs, and the broader Java Community Process membership.

Design and Components

The design centers on a runtime and compile-time module layer, a module graph, and the module descriptor format. Key components include the module path (analogous to Classpath (Java)), the module system implementation within the Java Virtual Machine, and supporting tools such as the module finder and service loader. Concepts like readability edges and qualified exports interact with existing Java Platform features including reflection and the ServiceLoader (Java) mechanism. Contributors drawn from organizations including Red Hat, IBM, and Google influenced trade-offs between backward compatibility and strong encapsulation.

Module Declaration and Descriptor (module-info.java)

Modules are declared via the module-info.java descriptor, which specifies directives such as requires, exports, opens, uses, and provides, modeled to capture relationships similar to CommonJS or ES Modules in other ecosystems. The descriptor affects compilation in javac and packaging tools like jar (file format), and it is processed by static analysis utilities such as jdeps. The choice of which packages a module exports parallels API design discussions seen in projects from Apache Software Foundation projects like Tomcat and Hadoop (software), and it enables build-time checks integrated into Maven (software) and Gradle (software).

Module Resolution, Readability, and Services

Resolution constructs a directed graph of modules where readability is an edge that permits access to exported packages; this model resembles dependency resolution algorithms used by Apt (package manager) and RPM Package Manager in different ecosystems. Service provisioning and consumption via provides and uses directives integrate with the ServiceLoader (Java) pattern and enable runtime discovery used in frameworks like Spring Framework and Jakarta EE. The system enforces transitive requires and supports qualified exports to manage split packages issues that previously affected multi-module deployments in Maven Central Repository artifacts.

Migration, Tooling, and Build Integration

Migration strategies included automatic modules, the unnamed module, and multi-release JARs to accommodate legacy Apache Commons libraries and frameworks such as Hibernate and Log4j. Tooling evolved with enhancements to Eclipse IDE, IntelliJ IDEA, and command-line tools in the JDK. Build integration patterns emerged in Maven (software) plugins, Gradle (software) modules, and container build pipelines leveraging jlink to create minimized runtime images for Kubernetes deployments and AWS Lambda-like use cases.

Security, Encapsulation, and Performance Impacts

Strong encapsulation reduces surface area for reflective access, mitigating risks highlighted in security advisories from organizations like CVE maintainers and prompting changes in frameworks relying on deep reflection such as Hibernate and Spring Framework. JPMS influences class loading behavior within the Java Virtual Machine and can improve start-up time and memory footprint when used with jlink and ahead-of-time strategies seen in GraalVM. However, improper modularization can introduce runtime linkage errors and complicate security policies used by SELinux or enterprise identity systems.

Adoption, Criticism, and History

Adoption has been mixed: enterprise platforms such as IBM WebSphere and Oracle WebLogic incorporated module-aware deployments, while some open-source communities favored continued classpath approaches in Maven Central Repository artifacts. Critics pointed to migration complexity, the tension with OSGi approaches, and the difficulty of modularizing large monolithic codebases such as Eclipse (software)'s large projects. The system’s history involves proposals and debates in Project Jigsaw mailing lists, OpenJDK Enhancement Proposals, and contributions from industry stakeholders like Oracle Corporation, Red Hat, and Google that culminated in inclusion in JDK 9.

Category:Java platform