A framework throws `InaccessibleObjectException` (or 'Unable to make field accessible') when reflecting into your module. What is the root cause and how do you fix it correctly?

## The error `java.lang.reflect.InaccessibleObjectException` (message often: *Unable to make field private ... accessible: module X does not "opens P" to module Y*) is thrown when reflective code calls `field.setAccessible(true)` (or `method`/`constructor` `setAccessible`) on a member that the **Java Platform Module System (JPMS)** has encapsulated. ## Why it happens — the default is closed A **module** strongly encapsulates its packages. JPMS distinguishes two kinds of access: - **Normal access** to *public* members of *exported* packages — controlled by `exports`. - **Deep reflective access** to *any* member (including `private`) at run time — controlled by `opens`. Key trap: even if a package is **exported**, that does NOT grant deep reflective access. Reflection that flips `setAccessible(true)` on a non-public member needs the package to be **opened**. By default packages are not opened, so frameworks that mutate private fields fail. Why do frameworks do this? JSON mappers (Jackson), ORMs (Hibernate/JPA), DI containers (Spring), and serializers routinely read and write **private** fields of your objects via reflection. Without `opens`, the JVM refuses, and you get `InaccessibleObjectException`. ## The correct fixes (in order of preference) ### 1. Qualified `opens` in your module-info If you own the module, open exactly the package to exactly the framework: ```java module com.example.app { requires com.fasterxml.jackson.databind; exports com.example.app.api; opens com.example.app.model to com.fasterxml.jackson.databind; } ``` This is the tightest, safest fix: only Jackson can reflect into `com.example.app.model`, and only that package is exposed. ### 2. Unqualified `opens` ```java opens com.example.app.model; ``` Opens the package to *all* modules for reflection. Use when you can't name the consumer (e.g., several frameworks) but still want package-level scope. ### 3. `open module` ```java open module com.example.app { ... } ``` Every package is opened for reflection. Convenient for legacy/heavily-reflected modules, but it discards package-level encapsulation, so use sparingly. ### 4. `--add-opens` launcher/compiler flag When you **cannot** edit the offending module's `module-info` (third-party code, or a quick migration): ``` --add-opens com.example.app/com.example.model=com.framework ``` For classpath (non-modular) code use `ALL-UNNAMED` as the target: ``` --add-opens java.base/java.lang=ALL-UNNAMED ``` Flags can also go in a JAR's `MANIFEST.MF` (`Add-Opens:`) or the `JDK_JAVA_OPTIONS` env var. Treat flags as an escape hatch, not a design choice — they undo encapsulation invisibly and must be repeated everywhere the app runs. ## What does NOT fix it - Adding `exports` — that grants normal access to public members, not reflection into private ones. - Making the field `public` — reflection on a public field of an *exported* package can work, but you usually don't want to break your data model's encapsulation just to satisfy a framework; `opens` is the intended tool. - Adding `requires` — readability doesn't grant reflective access. ## How to diagnose quickly The exception message names both modules and the missing directive: *module X does not "opens P" to module Y*. Read it literally: X needs `opens P to Y;` (or you supply `--add-opens X/P=Y`). ## Note on JDK internals Reflecting into JDK internal packages (e.g., `java.base/java.lang`) is increasingly restricted; since JDK 16 illegal reflective access is denied by default, and JDK 17+ has no relaxation flag for *its own* internals beyond explicit `--add-opens`. For your own modules, just use `opens`. ## One-line takeaway `InaccessibleObjectException` = reflection without `opens`. Fix by `opens <package> to <framework>;` in module-info (preferred), or `--add-opens` when you can't edit it — never by confusing it with `exports`.