All 15 Java Platform Module System (JPMS) questions
More in Java Platform Module System (JPMS)
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 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? 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 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? How would you use the 'requires static' directive to declare an optional, compile-time-only dependency that isn't required to be present at runtime?
Advertisement
Java › Java Platform Module System (JPMS)

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?

Advanced

Answer

Any code placed on the traditional classpath (rather than the module path) is automatically treated as part of a special 'unnamed module', which is granted implicit access to read every other named module's exports (a pragmatic, deliberately permissive compatibility measure), and conversely, code in named modules can be configured to read the unnamed module too -- this design lets pre-existing, non-modularized JARs continue working essentially unchanged when placed on the classpath, providing a gradual migration path where an application can mix explicitly modularized code with legacy classpath-based dependencies during a transition period, rather than requiring an all-or-nothing simultaneous migration of an entire dependency tree.
# Running with a MIX of the module path (explicitly modularized code) and classpath (legacy JARs)
java --module-path mymodules --add-modules com.example.myapp \
     --class-path legacy-lib.jar \
     -m com.example.myapp/com.example.myapp.Main

# legacy-lib.jar (unnamed module) can freely use any named module's exports,
# and com.example.myapp can be configured to use legacy-lib.jar's classes too
Real-world example A large legacy application incrementally adopts JPMS by modularizing its own core application code first while leaving several older, unmaintained third-party dependencies on the traditional classpath (as part of the unnamed module), achieving partial modularization benefits without needing to wait for or force those legacy dependencies to be updated with proper module declarations first.

Common follow-ups: What are 'automatic modules', and how do they provide an intermediate step between the unnamed module and a fully-declared named module for a JAR without a module-info.java?;What specific compatibility risks or limitations remain even with the unnamed module's permissive design?

Class Loading & Bytecode Verification;Build Tools: Maven & Gradle
All 15 Java Platform Module System (JPMS) questions