InaccessibleObjectExceptionの直し方｜Java 17

java.lang.reflect.InaccessibleObjectException: Unable to make field ... accessible: module java.base does not "opens java.util" to unnamed module は、プログラム（またはライブラリ）が、リフレクションで JDK の内部の private なフィールドを使おうとして、JDK 17 以降で拒否されたときの例外です。

Exception in thread "main" java.lang.reflect.InaccessibleObjectException: Unable to make field transient java.lang.Object[] java.util.ArrayList.elementData accessible: module java.base does not "opens java.util" to unnamed module @2a139a55

JDK 11 までは警告だけで動いていたコードが、JDK 17 に上げたとたんに止まるのが典型です。

確認環境：OpenJDK 8・11・17・21・25 で、ArrayList の private フィールド elementData を setAccessible(true) する同じ class ファイルを動かしました（確認日 2026年10月11日）。

JDK の版で、動きが変わる

Field f = ArrayList.class.getDeclaredField("elementData");
f.setAccessible(true);     // ← JDK 17 以降はここで例外

JEP 403 により、JDK 17 から JDK の内部は強くカプセル化され、--illegal-access で以前の動きに戻すことはできなくなりました（JEP 403 では、JDK 16 で既定が deny になったことも説明されています）。JDK 11 のときに出ていた illegal reflective access の警告は、JDK 17 で止まる場所の予告です。

エラー文から --add-opens の書き方を作る

module java.base does not "opens java.util" to unnamed module
       ~~~~~~~~~             ~~~~~~~~~~~~        ~~~~~~~~~~~~~~
       モジュール               package           開ける相手

java --add-opens java.base/java.util=ALL-UNNAMED -jar app.jar

エラー文の opens ○○ の package と、同じ package を指定します。 別の package で同じエラーが続くときは、エラー文が変わるので、1つずつ足していきます。

--add-opens を渡す方法

JAR のマニフェストの Add-Opens は、java -jar で起動したときだけ効きました。 JEP 403 でも、--add-opens とマニフェストの Add-Opens が、特定の package を開ける方法として挙げられています。

テストを別の JVM で動かす設定のときは、java コマンドに付けた --add-opens はテストの JVM には渡りません。テストだけで例外が出るときは、テストの JVM の引数を確かめます。

まず、ライブラリの版を確かめる

このエラーは、自分のコードではなく、ライブラリの中で起きていることがほとんどです。スタックトレースの at の行を下にたどり、どのライブラリが setAccessible を呼んでいるかを探します。

（スタックトレースの形の例）

    at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(...)
    at java.base/java.lang.reflect.Field.setAccessible(...)
    at com.example.lib.XxxUtil.copy(XxxUtil.java:42)     ← ここが原因のライブラリ

JDK 17 に対応した版が出ていれば、そちらに上げるのが根本的な直し方です。--add-opens は、JDK の内部に頼る動きを残すことになるため、ライブラリを上げるまでのつなぎにします。スタックトレースの読み方は、既存の記事「Javaスタックトレースの読み方｜Caused byの意味と原因の探し方」で扱っています。

自分のコードなら、例外を出さずに確かめられる

Field f = ArrayList.class.getDeclaredField("elementData");
System.out.println(f.trySetAccessible());     // false（例外にならない）

trySetAccessible() は、使えない場合に例外ではなく false を返しました。 ただし、JDK の内部のフィールドを使わずに、公開されているメソッド（この例なら size() など）で書き直すのが本来の形です。リフレクションの使い方は、既存の記事「Javaリフレクションの使い方｜getDeclaredField・invoke」で扱っています。

確認の手順（チェックリスト）

よくある質問

Q. JDK 8 から JDK 17 以降に上げるとき、ほかに出やすいエラーは。 A. class ファイルの版の違いで出る UnsupportedClassVersionError があります。関連記事の「UnsupportedClassVersionErrorの直し方｜版の対応表」で扱っています。

まとめ

• リフレクションで JDK の内部を使おうとして、JDK 17 以降で拒否された例外
• JDK 11 の illegal reflective access の警告は、17 で止まる予告
• JDK 17 から --illegal-access は効かない（JEP 403）
• エラー文の module ○○ と opens △△ から --add-opens ○○/△△=ALL-UNNAMED
• まずライブラリを新しい版に。--add-opens はつなぎ

参考・出典

確認日はいずれも 2026年10月11日です。

• JEP 403「Strongly Encapsulate JDK Internals」：https://openjdk.org/jeps/403

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。