What is the difference between `exports` and `opens` (including `opens...to` and an `open module`), and why is `opens` needed for reflection-heavy frameworks?

## Two kinds of access JPMS distinguishes two ways one module reaches into another: 1. **Normal access** — compiling and running against another module's *public* types. Controlled by `exports`. 2. **Deep reflective access** — using the reflection API (`java.lang.reflect`) to inspect and manipulate members, including **private** ones, often via `field.setAccessible(true)`. Controlled by `opens`. Before Java 9, reflection could reach any member of any class with `setAccessible(true)`. JPMS introduced **strong encapsulation**: by default a module's internals are sealed even against reflection. This is great for safety but breaks tools that depend on reaching into your objects. ## `exports` — public API, no deep reflection `exports P` makes the **public/protected** types of package P usable by readers at **compile time and run time** through normal references. It does **not** by itself permit deep reflection into private members. (Reflecting over *public* members of an exported type is allowed; setAccessible on a *non-public* member of a merely-exported package is denied.) ## `opens` — deep reflective access, runtime only `opens P` grants **deep reflective access** to all types in P at **runtime**: readers can reflectively access public, protected, package-private, and **private** members, and call `setAccessible(true)` successfully. Important properties: - It is **runtime-only** — `opens` gives no compile-time access. (`opens` without `exports` means: you can reflect on it but cannot reference its types in source.) - It is exactly what serialization/DI/ORM frameworks need, because they read and write your private fields reflectively. ```java module com.acme.app { opens com.acme.app.model; // frameworks can reflect into model classes } ``` ## Qualified opens: `opens P to M1, M2` Unqualified `opens P` opens the package to **every** module that reads you. A **qualified** open restricts it: ```java opens com.acme.app.model to com.fasterxml.jackson.databind; ``` Now only the named module(s) get deep reflective access; everyone else is still locked out. This is the recommended form — you grant exactly the framework that needs it and no more. (The same `...to` qualification exists for `exports`: `exports P to M` is a **qualified export**, visible only to listed modules — useful for internal APIs shared between your own modules.) ## The `open module` Prefixing the declaration with `open` opens **every** package for reflection without enumerating them: ```java open module com.acme.app { requires ...; exports ...; // you may still list exports for normal access } ``` An `open module` cannot also contain individual `opens` directives (they'd be redundant). It is a **blunt instrument** — convenient during migration when many packages need reflective access, but it surrenders strong encapsulation for the whole module. Prefer per-package, qualified `opens` in finished code. ## Why frameworks need this - **Jackson / Gson / JAXB** serialize and deserialize by reflecting over fields, often private. - **Hibernate / JPA** populate entity private fields and may create proxies. - **Spring / CDI** perform field and constructor injection reflectively. Without opening the package containing those classes, you get `InaccessibleObjectException` ("Unable to make field ... accessible: module ... does not opens ... to ..."). The fix is to `opens` (preferably `opens ... to <framework module>`) the package holding the reflected types. ## Decision guide - Expose an API for normal use → `exports`. - Let a framework reflect into private members → `opens` (qualified to that framework). - Need both → list both `exports P` and `opens P` (they're independent). - Whole module is reflection-heavy during migration → `open module`, then tighten later.