All 15 Java Platform Module System (JPMS) questions
More in Java Platform Module System (JPMS)
What is the difference between 'exports' and 'opens' in a module-info.java file, and why does reflection-heavy code (like many dependency injection or serialization frameworks) specifically require the latter? What is an automatic module, and how does placing a plain (non-modularized) JAR on the module path (rather than the classpath) differ from leaving it on the classpath as part of the unnamed module? How does the ServiceLoader/Service Provider Interface pattern integrate with JPMS using the 'uses' and 'provides ... with' directives, replacing the older META-INF/services file-based mechanism? How would you write and run a basic 'Hello World' JPMS-modularized application from scratch, including the module-info.java, directory structure, and the specific javac/java command-line invocations needed? What is a qualified export (exports package to specificModule), and when would you use it instead of a plain, unqualified export? What is the difference between 'requires' and 'requires transitive', and how does transitive dependency propagation work in the module system? How does the 'unnamed module' work, and how does JPMS maintain backward compatibility with the vast ecosystem of pre-existing JARs that were never designed with modules in mind? How would you use jlink to create a custom, minimal Java runtime image containing only the specific modules an application actually needs, and what deployment benefits does this provide? How would you diagnose and resolve common JPMS migration errors, such as 'package is not visible' or a split package conflict, when modularizing an existing large application? How does JPMS's strong encapsulation interact with reflection-heavy frameworks and libraries that predate the module system, and what specific JVM flags (like --add-opens) exist as an escape hatch for cases where proper module declarations aren't feasible?
Advertisement
Back to results for “Performance”
Java › Java Platform Module System (JPMS)

What are the practical trade-offs and adoption challenges that have led many real-world Java projects to NOT fully adopt JPMS modularization even years after its introduction, despite its stated benefits?

Intermediate

Answer

Despite JPMS's genuine architectural benefits (strong encapsulation, explicit dependencies, custom runtime images via jlink), real-world adoption has been notably slower and more partial than initially anticipated, due to several practical friction points: the substantial migration effort required for large existing codebases (especially those with extensive reflection-based framework usage needing opens directives throughout), the split-package and automatic-module-naming complications when depending on a large tree of third-party libraries not all simultaneously modularized, and the reality that many of JPMS's core benefits (dependency management, some encapsulation) are already reasonably well-served for many teams by existing build tools (Maven/Gradle) and coding conventions, reducing the perceived urgency of migration -- as a result, many production Java applications today continue running primarily on the traditional classpath (as the unnamed module) even on modern JDK versions, adopting JPMS more selectively (like using jlink for a custom runtime image) rather than pursuing full, comprehensive modularization of their entire dependency tree.
# A pragmatic, partial-adoption approach many real-world projects actually take:
# Keep the application's own code and dependencies on the traditional classpath,
# but still benefit from SOME jlink advantages by treating the whole classpath-based
# application as effectively one large 'automatic module' equivalent for jlink packaging purposes,
# without undertaking full explicit modularization of every individual dependency
Real-world example A mature enterprise Java application with hundreds of third-party dependencies evaluates full JPMS modularization but ultimately decides the migration cost (particularly resolving reflection-based framework access and split-package conflicts across their extensive dependency tree) outweighs the practical benefit for their specific situation, instead continuing to rely on their existing Maven-based dependency management while running on a modern JDK primarily via the classpath/unnamed-module approach.

Common follow-ups: What specific JPMS benefits remain compelling enough that a team might pursue partial adoption (like just using jlink) even without full modularization?;How has the broader Java ecosystem's tooling and library support for JPMS evolved and matured since its initial Java 9 introduction?

Build Tools: Maven & Gradle;Diagnostics & Performance
All 15 Java Platform Module System (JPMS) questions