What is module readability in JPMS, and how does a module obtain it?

## What readability is In the **Java Platform Module System (JPMS)**, a **module** is a named group of packages described by `module-info.java`. Modules form a graph. **Readability** is the directed edge in that graph: if module **A reads module B**, then A is permitted to depend on B — to see and use the types B makes available. If A does not read B, then *nothing* in B is visible to A, even B's exported public types. Readability is therefore the first gate. ## How you obtain readability: `requires` You declare it in the consuming module: ```java module com.example.a { requires com.example.b; // A now reads B } ``` That single directive makes the edge A → B. After this, A can use the *exported* public types of B. ## The two conditions for access Readability alone is not enough. For code in A to use a type `T` defined in B, **both** must hold: 1. **Readability:** A reads B (`requires com.example.b`). 2. **Accessibility:** `T` is `public` *and* lives in a package that B `exports`. Missing either one means A cannot touch `T`. (This pairing — readability + accessibility — is the heart of module access rules. Reflection adds a third concept, `opens`, covered separately.) ## Implicit readability of `java.base` Every module automatically reads `java.base` (the module containing `java.lang`, `java.util`, etc.) without declaring it. That is why you never write `requires java.base;` — it is implied. ## `requires transitive` — implied readability Sometimes A's *public API* mentions types from B. For example, a method in A returns a `com.example.b.Widget`. Any module C that uses that method must also read B, or it cannot even name the return type. Forcing every C to add `requires B` is fragile. Instead, A declares: ```java requires transitive com.example.b; ``` Now any module that reads A **implicitly also reads B**. This is called *implied readability*. Rule of thumb: if a type from B appears in A's exported (public) signatures, use `requires transitive`; if B is purely an internal implementation detail, use plain `requires`. ## `requires static` — optional at run time ```java requires static com.example.annotations; ``` `requires static` means the dependency is needed to **compile** but is **optional at run time**. Common for compile-time-only annotation libraries or optional integrations: the module compiles against them, but if they are absent at run time, the module still loads. ## Resolution at startup When the JVM starts, it resolves the module graph from the root modules, following `requires` edges. If a required module is missing, you get a clear error at startup (e.g. *module not found*), not a mysterious failure deep into execution. This fail-fast behavior is a key benefit over the old classpath. ## Summary - Readability = "A may depend on B", created by `requires B` in A. - It is the *first* of the two access conditions; the second is accessibility (public + exported). - `java.base` is read implicitly. - `requires transitive` propagates readability to A's consumers (for re-exposed API types). - `requires static` = compile-time-only / optional-at-runtime dependency.