What is 'strong encapsulation' in JPMS, and how does it change the meaning of 'public'?

## What 'encapsulation' meant before modules **Encapsulation** is hiding internal details behind a controlled interface. Java's access modifiers (`private`, package-private, `protected`, `public`) handle this *within and between classes*. But at the JAR level there was a gaping hole: anything declared **`public`** was reachable by **all** code on the classpath. If you wanted a class usable by other classes in your own library, it had to be `public` — and then it was equally usable by everyone else, including consumers who should never touch your internals. Library authors documented 'do not use' and put classes in `internal` packages, but nothing **enforced** it; reflection could reach anything regardless. ## What strong encapsulation adds **Strong encapsulation** is JPMS's guarantee that a module's packages are **hidden by default** and become accessible to other modules **only when the module explicitly exports them**. The directive is `exports`: ```java module com.example.lib { exports com.example.lib.api; // visible to other modules // com.example.lib.internal is NOT exported -> hidden } ``` Here `com.example.lib.internal` stays private to the module even if its classes are declared `public`. ## The new meaning of `public` The key conceptual shift: **`public` is necessary but no longer sufficient** for another module to use a type. Cross-module accessibility now requires **all** of: 1. the member/type is `public` (the language-level modifier), AND 2. the package containing it is **exported** by its module, AND 3. the consuming module **reads** the providing module (has a `requires` edge to it). So within a module, `public` works as it always did. Across modules, a `public` type in a non-exported package is invisible — you cannot import it, compile against it, or (by default) reflect into it from another module. People summarize this as 'public no longer means public to everyone.' ## Reflection and the `opens` directive Reflection (inspecting/invoking code at runtime via the `java.lang.reflect` API) used to bypass all access checks — it could read private fields of any class anywhere. Strong encapsulation closes that door too: by default you cannot reflect into a non-open package of another module. But frameworks (dependency injection, serialization, ORMs) rely on deep reflection. JPMS provides two graduated tools: - **`exports pkg;`** → grants *compile-time and normal* access to a package's public API. - **`opens pkg;`** → grants *deep reflective* access (including to non-public members) at runtime, but **not** compile-time API access. This separation lets a module say 'frameworks may reflect over my entities, but no one may compile against this package as API.' You can also target a specific module: `exports pkg to other.module;` (a **qualified export**) or `opens pkg to framework.module;`. ## Why 'strong' It is called *strong* encapsulation because, unlike the old convention-and-documentation approach, it is **enforced by the runtime and compiler**. An attempt to access a non-exported package fails to compile, and a reflective attempt throws `IllegalAccessException` unless the package is open. Boundaries that used to be honor-system are now hard walls. ## Relationship to reliable configuration The two goals are complementary. **Reliable configuration** decides *which modules and dependencies exist* (the graph). **Strong encapsulation** decides *what inside each module is reachable* across that graph. A consumer needs both: a `requires` edge (configuration) and an `exports` on the target package (encapsulation) to use another module's API. ## Practical payoff Library authors gain a real, enforced API surface: implementation packages can finally be private, free to change without breaking consumers; consumers get a smaller, intentional API and can no longer accidentally couple to internals. That is the durable architectural value of strong encapsulation.