Java17模块系统能否让内部依赖继承上层开放的反射访问权限？

Java 17 原生模块系统无法直接实现你需要的反射权限自动透传能力。JPMS的访问控制规则严格按模块边界隔离，opens指令的目标模块必须显式指定，权限不会自动继承给当前模块依赖的其他模块。

以下方案按优先级从高到低排序：

方案1：在mylib中封装所有反射操作 #

将internal需要用到的反射逻辑全部封装到mylib的内部工具类中，由mylib完成对app传入类的反射访问，再将结果传递给internal使用。

• 优势：完全不需要调整app侧的模块声明，app仅需按预期opens ... to mylib即可，internal模块全程不会暴露给上层使用者，后续替换internal依赖时无需修改app任何代码，兼容性最优。
• 代码示例（mylib侧实现）：

// mylib内部工具类，不对外导出
package some.pgk.from.mylib.internal;
import java.lang.reflect.Field;
public class ReflectDelegate {
    public static Object getFieldValue(Object obj, String fieldName) throws NoSuchFieldException, IllegalAccessException {
        Field field = obj.getClass().getDeclaredField(fieldName);
        field.setAccessible(true);
        return field.get(obj);
    }
}

internal需要访问app类的字段时，调用ReflectDelegate的对应方法即可，不需要直接操作app的类。

方案2：合并internal模块到mylib中 #

修改打包配置，将internal的字节码直接合并进mylib的Jar包，将其作为mylib的一部分而非独立模块存在。

• 优势：改造成本极低，仅需调整构建配置即可实现。以Maven为例，使用maven-shade-plugin即可完成合并，还可对internal的包名做重定位避免和上层依赖冲突。合并后mylib的模块声明可直接移除requires internal，app开放给mylib的反射权限自然可以被原internal的代码访问，完全隐藏内部实现细节。
• 模块声明调整后示例：

module mylib {
    exports some.pgk.from.mylib;
    // 不再需要requires internal
}

方案3：使用JVM启动参数兜底（仅适用于受控部署场景） #

如果前两种方案都无法落地，且你的库的运行环境可控，可以要求app侧添加JVM启动参数为internal开放对应包的全局反射权限：

--add-opens some.pkg.from.app/some.pkg.from.app=internal

该方案不推荐作为公开库的通用方案，会破坏模块系统的封装性，且仍然会暴露internal模块的存在。

内容的提问来源于stack exchange，提问作者tobain