强封装：模块边界与反射

JEP 403 改变了什么01

JEP 403 的关键不是「默认值又改了」，而是「退路被删除」。依赖 sun.*、jdk.internal.* 或对 java.lang 等包做 setAccessible 的库，必须在 17 上显式适配。

$ java --illegal-access=permit -cp out ReflectDemo
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0
type=InaccessibleObjectException
msg=Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module @...

反射检查发生在哪里02

反射访问的检查发生在 AccessibleObject.setAccessible 与成员访问时：运行时先确认目标包是否对调用方模块 opens，再决定是否允许。失败抛 InaccessibleObjectException。

import java.lang.reflect.Field;

Field f = String.class.getDeclaredField("value");
f.setAccessible(true);

type=InaccessibleObjectException
msg=Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module @...

1. String.class.getDeclaredField("value") 本身可以成功：拿到 Field 对象不等于获得访问权。
2. setAccessible(true) 触发模块访问检查；java.base 没有向调用方 opens java.lang。
3. 异常消息给出目标成员、所属模块/包，以及「没有向谁 opens」。
4. 调用方是 classpath 代码时，目标模块名显示为 unnamed module；命名模块则显示模块名。

注意：getDeclaredField 能拿到私有字段，是反射 API 的设计；真正被强封装拦住的是「使用」它。所以不要把「能拿到 Field」误判为「封装没生效」。

add-opens 如何放行03

--add-opens <module>/<package>=<target> 在运行时把指定包打开给目标模块。它只影响反射的深度访问，不会让代码在编译期看到该包。

# 把 java.base/java.lang 打开给 classpath 代码
java --add-opens java.base/java.lang=ALL-UNNAMED -cp out ReflectDemo
# opened=true

• 目标写 ALL-UNNAMED 表示 classpath 上的未命名模块；命名模块要写具体模块名。
• 可以重复传多个 --add-opens，每个包一条；不要用一个宽泛的包覆盖所有需求。
• --add-opens 是运行时参数；编译期访问未导出类型要用 --add-exports。
• 模块化应用可以在 module-info 里用 opens ... to ...，比命令行参数更可审计。

# --add-exports：让未导出的 public 类型在编译期可见
javac --add-exports java.base/sun.nio.ch=ALL-UNNAMED -d out ExportDemo.java
java --add-exports java.base/sun.nio.ch=ALL-UNNAMED -cp out ExportDemo
# sun.nio.ch.DirectBuffer

定位：jdeps 与运行日志01

先用 jdeps --jdk-internals 找静态引用，再用运行日志找反射访问。前者能列出编译进字节码的内部 API，后者只能在真实执行路径上暴露。

$ jdeps -J-Duser.language=en --jdk-internals out/ExportDemo.class
ExportDemo.class -> java.base
   ExportDemo -> sun.nio.ch.DirectBuffer   JDK internal API (java.base)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.

• jdeps --jdk-internals -R 递归扫描目录或 jar，适合在升级前做全量盘点。
• jdeprscan --release 17 --for-removal 找使用了待移除 API 的类，和内部 API 检查互补。
• jdeps 看不到纯反射字符串（如 Class.forName("sun.misc.Unsafe")），需要结合运行日志和库文档。
• 运行日志里的 InaccessibleObjectException 会直接给出模块与包，是最可靠的反射线索。

最小化兼容参数02

1. 确认报错的目标模块与包，记录调用方是 classpath 还是命名模块。
2. 先查该库是否有支持 17 的新版本；能升级就不要加参数。
3. 如果必须兼容，只打开报错的那个包，不要打开整个 java.base。
4. 同时检查编译期是否需要 --add-exports；运行时 --add-opens 不解决编译错误。
5. 为每条参数记录原因、责任人和移除计划，纳入升级看板。

# 只打开需要的包，并限定目标模块
java --add-opens java.base/java.lang=com.example.app \
     --add-opens java.base/java.util=com.example.app \
     -jar app.jar

验证与回归03

• 在 CI 里用目标 JDK 跑完整测试，不要只在 IDE 里切换 JDK。
• 打开 -Xlog:class+load 或依赖检查，确认没有旧版库被间接引入。
• 对序列化、ORM、Mock、字节码增强框架做专项回归，它们最容易反射 JDK 内部。
• 把 --add-opens 作为告警项：新增一条就要求评审，避免无声累积。
• 升级后重新跑 jdeps，确认内部 API 引用没有增加。

# 启动时确认模块与封装状态
java --show-module-resolution -version 2>&1 | head -20

# 列出运行时新增的 opens（需要 --show-module-resolution 或启动日志）

强封装问题通常在启动或首次反射时暴露，但有些路径只在特定业务分支执行。测试覆盖要包含序列化、动态代理、模板引擎和依赖注入的真实使用场景。

先猜再看01

费曼自检：能否讲清因果02