All 15 Java Platform Module System (JPMS) questions
More in Java Platform Module System (JPMS)
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 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 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? 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)

What is a qualified export (exports package to specificModule), and when would you use it instead of a plain, unqualified export?

Intermediate

Answer

A qualified export (exports package.name to module1, module2) makes a package accessible ONLY to the specifically named target module(s), rather than to every module that might require yours -- this is useful for exposing an internal-ish package needed by a small number of closely-related, trusted modules (like a testing module needing access to internals for white-box testing, or an internal SPI implementation module) without making that package part of your module's genuinely public, broadly-supported API surface, striking a middle ground between full encapsulation and full public exposure.
module com.example.core {
    exports com.example.core.api;  // fully public, unqualified
    exports com.example.core.internal to com.example.core.test, com.example.core.plugin;
    // 'internal' package accessible ONLY to these two specific, trusted modules -- not to the general public
}
Real-world example A library's internal package containing implementation details needed by its own dedicated test module (for white-box testing of private-ish logic) uses a qualified export granting access specifically to that test module by name, keeping the package genuinely hidden from all other, unrelated consumer modules that only need the library's standard public API.

Common follow-ups: Why might a qualified export still be considered a form of tight coupling between modules, even though it's more restrictive than a full export?;How would you add an additional trusted target module to an existing qualified export later, if a new legitimate consumer emerges?

OOP & Classes;Testing ASP.NET Core Applications
All 15 Java Platform Module System (JPMS) questions