Readability, Accessibility & exports vs opens

## Background: what a module is The **Java Platform Module System (JPMS)**, introduced in Java 9, groups packages into a named unit called a **module**. A module is described by a file `module-info.java` at the root of its source, which compiles to `module-info.class`. Inside it you declare what the module needs and what it offers. A tiny example: ```java module com.example.app { requires com.example.lib; // I depend on another module exports com.example.app.api; // I let others use this package's public API opens com.example.app.model; // I let others reflect into this package } ``` ## The problem these keywords solve Before modules, every public class in any JAR on the classpath was visible to everyone, and reflection could reach *anything*. Modules introduce **strong encapsulation**: by default, packages inside a module are completely hidden from other modules. You must explicitly open holes. `exports` and `opens` are two *different kinds* of holes. ## `exports` — normal access to a public API `exports a.b.c;` says: *other modules that read mine may use the **public** types in package `a.b.c` the normal way.* "Normal way" means: - **Compile time:** their code can `import a.b.c.Foo;` and call `Foo`'s public/protected members. The compiler allows it. - **Run time:** the JVM allows the same access at execution. Crucially, `exports` only exposes what is *already* `public` (and `protected` members of public classes, to subclasses). Package-private and private members stay hidden. And `exports` gives **no** special reflective powers: you cannot use reflection to call a private method of an exported type from another module. ## `opens` — deep reflective access `opens a.b.c;` says: *at **run time**, other modules may use **reflection** to access **all** members of all types in `a.b.c`, including non-public classes and private fields/methods, including calling `setAccessible(true)`.* What `opens` does **not** do: it does not grant normal compile-time access. If a package is `opens` but not `exports`, you cannot `import` its types and call them directly in source code — you can only reach them reflectively at run time. ## Why both exist They serve two different consumers: 1. **API consumers** call your code directly. They need `exports`. 2. **Reflection-based frameworks** (JSON mappers like Jackson, ORMs like Hibernate, dependency injection like Spring, serialization, testing tools) inspect and mutate your objects' *private* internals at run time. They need `opens`. For example, Jackson sets a private field directly when deserializing JSON into your object; without `opens`, that throws `InaccessibleObjectException`. A package can be both exported and opened, just exported, just opened, or neither. ## Qualified forms Both can be restricted to named modules: ```java exports a.b.c to com.example.client; // only this module gets compile/run access opens a.b.c to com.fasterxml.jackson.databind; // only Jackson can reflect ``` Qualified exports/opens keep the hole as small as possible — good for internal-but-shared packages. ## `open module` If you write `open module com.example.app { ... }`, **every** package in the module is implicitly opened for reflection (but you still must `exports` packages for normal access). This is a blunt convenience for legacy code or heavily reflected modules. ## The mental model - `exports` = "you may *use my public API* the normal way (compile + run)." - `opens` = "you may *reflect into my internals* at run time, even private parts." They are orthogonal: one is about ordinary access to public things, the other is about reflective access to everything.