历史。 在Java 9之前，反射可以通过setAccessible(true)任意规避访问修饰符，随意破坏封装。引入**Java平台模块系统（JPMS）**后，默认为模块提供了强封装，在此情况下，模块必须明确授予权限以进行深入的反射访问其内部包。
问题。 当一个模块的代码尝试使用MethodHandles或核心反射访问另一个模块包中的非公共字段时，JVM会执行严格的可访问性检查。此验证确保目标包已明确对调用者的模块开放。没有该权限，JVM会抛出InaccessibleObjectException（或对旧版反射抛出IllegalAccessException），无论是否安装了SecurityManager，或通过VarHandle访问字段。
解决方案。 模块必须在其module-info.java中声明opens package.name [to specific.module];，或者应用程序必须使用--add-opens source.module/package.name=target.module标志启动。该指令动态修改模块的内部可访问性图，将目标模块添加到有权对此包的私有成员进行深入反射的模块集合中。
// 模块：app.core (module-info.java) module app.core { // 包com.app.internal未被打开 exports com.app.api; } // 模块：framework.inject public class Injector { public void inject(Object target) throws Throwable { MethodHandles.Lookup lookup = MethodHandles.privateLookupIn( target.getClass(), MethodHandles.lookup() ); // 在没有--add-opens的情况下抛出InaccessibleObjectException VarHandle handle = lookup.findVarHandle( target.getClass(), "secretField", String.class ); handle.set(target, "injected"); } }
一个开发团队将其单体Spring应用程序迁移到Java模块系统，将代码库划分为核心业务逻辑模块(app.core)和一个独立的依赖注入框架模块(framework.inject)。在部署后，应用程序在Bean初始化期间崩溃，出现InaccessibleObjectException，当框架尝试将配置值注入位于app.core内部com.app.internal包中的私有字段时。
评估了三种潜在的架构解决方案。第一种方法是将所有可注入类移至app.core内的已导出包。虽然这会解决即时的访问违规，但从根本上违反了封装原则，通过向所有其他模块暴露内部实现细节，增加了维护负担并扩大了未来安全审计的攻击面。第二种解决方案建议使用--add-exports JVM参数将内部包暴露给框架模块。然而，虽然--add-exports为公共类型提供了编译时和运行时可见性，但显然不允许对私有成员进行深入反射，因此不适用于需要修改私有状态的Spring字段注入机制。第三种选择是使用定向命令行参数--add-opens app.core/com.app.internal=framework.inject。此方法在确保所有其他模块的严密源级封装的同时，仅显式授予依赖注入框架必要的权限，以对特定内部包执行深入反射。
团队最终选择了第三种方案，并在其部署脚本和Docker配置中记录了所需的--add-opens指令。此解决方案在开发过程中保持了模块系统的完整性，同时允许框架正确运行，从而成功迁移，并显式控制访问边界。
为什么在不同模块访问导出包中的私有字段时，setAccessible(true)失效，尽管没有SecurityManager**？**
候选人经常将包导出与开放混淆。exports指令仅使公共类型和成员可用于标准编译和调用；它并不授予压制Java语言访问检查所需的ReflectPermission。JPMS强封装独立于SecurityManager运作，直接由JVM的访问控制机制执行。要在非公共成员上启用setAccessible(true)，包必须被明确声明为open，或者整个模块必须被声明为open module。
MethodHandles.Lookup捕获机制如何影响跨模块的可访问性，为什么调用MethodHandles.lookup().in(targetClass)会降低查找的能力？
一个Lookup对象封装了其创建者的模块和包上下文的访问权限。当调用Lookup.in(targetClass)时，JVM会基于目标类的模块重新评估查找的权限。如果目标类位于一个不同的模块，该模块并没有将其包开放给查找的模块，则查找会被“降级”为PUBLIC模式，剥夺PRIVATE和MODULE的访问权限。为了在跨模块之间维护完整的访问权，目标模块必须明确将包开放给查找的模块，或者代码必须使用privateLookupIn，这要求目标类必须位于同一模块内或通过模块图可访问。
在JVM层面，--add-exports与--add-opens之间的根本区别是什么，为什么前者在依赖注入期间即使编译成功也会导致IllegalAccessException**？**
--add-exports标志将一个包添加到模块的导出列表，使目标模块能够在编译时和运行时访问公共类型。然而，此指令并未修改模块的“开放”集合，该集合控制深入反射。Java语言规范严格区分可读性（导出）与反射能力（开放）。依赖注入框架需要后者才能通过反射或VarHandle操作私有字段。因此，虽然--add-exports满足编译器并允许方法调用，但运行时尝试修改私有状态仍将失败。只有--add-opens将包添加到可进行深入反射的包集合中，从而允许框架修改私有字段的值。