java 9模块系统（jpms）不支持跨模块直接传递对象或运行时契约验证，module-info.java仅声明静态可见性契约；对象传递需通过serviceloader等运行时机制实现，契约验证需结合接口、注解与显式校验。

Java 9 引入的模块系统（JPMS）本身不支持跨模块直接传递对象变量或运行时契约验证。module-info.java 的作用是声明模块的依赖、导出、开放等静态元数据，它在编译期和启动期生效，不提供对象共享机制或动态契约检查能力。真正实现“跨模块对象传递”和“契约验证”，需结合模块声明 + 运行时协作设计。

module-info.java 只负责“可见性契约”，不负责“对象传递”

模块系统通过 exports 和 opens 控制包级访问权限，这是编译/加载阶段的静态契约：

• exports com.example.api;：允许其他模块使用该包下的 public 类型（如接口、DTO）
• exports com.example.api to com.example.service;：精准导出，仅限指定模块可见
• opens com.example.config to java.desktop;：仅对反射开放（如 JavaFX 序列化），不用于常规对象传递

⚠️ 注意：即使导出成功，模块 A 中 new 出的对象仍需通过明确的 API（如接口、工厂、服务）被模块 B 获取——module-info 本身不做实例创建或传递。

用服务（ServiceLoader）实现松耦合的对象契约与传递

这是 JPMS 推荐的跨模块协作方式：定义接口在 API 模块，实现类在服务模块，通过 provides/uses 声明契约，运行时按需加载。

• API 模块（com.example.api）中定义接口：
  public interface DataProcessor { DataResult process(DataInput input); }
• API 模块的 module-info.java：
  module com.example.api { exports com.example.api; }
• 服务模块（com.example.impl）实现接口，并声明：
  module com.example.impl { requires com.example.api; provides com.example.api.DataProcessor with com.example.impl.DefaultProcessor; }
• 调用方模块（com.example.app）使用：
  ServiceLoader.load(DataProcessor.class).findFirst() → 得到具体实例，完成对象传递

✅ 契约由接口定义（编译期检查），对象由 ServiceLoader 实例化（运行时解耦），module-info 确保模块间依赖合法。

用模块层契约 + 运行时校验补足“强契约验证”

若需验证对象内容是否符合业务规则（如非空、范围、格式），module-info 无法胜任，但可配合以下方式：

• 在 API 模块定义带 JSR-303 注解的 DTO（如 @NotNull, @Min(1)），并导出校验逻辑工具类
• 服务模块接收对象后，显式调用 Validator.validate(obj)；失败则抛出 ConstraintViolationException
• 模块声明中确保校验库（如 Hibernate Validator）被正确 require 和 open（若需反射访问私有字段）

例如：
module com.example.api { requires java.validation; exports com.example.dto; }
此时契约 = 接口 + 注解 + 显式校验调用，module-info 仅保障校验能力可用。

避免常见误区：不要试图绕过模块边界

以下做法违背 JPMS 设计初衷，易导致不可预测行为：

• 用 --add-opens 打开所有包给所有模块（破坏封装）
• 在 module-info 中 opens 整个包只为传对象（应只开放必要反射场景）
• 让模块 B 直接 new 模块 A 的实现类（违反封装，且模块 A 未导出实现包）
• 把 DTO 放在主模块里，其他模块都 require 主模块（形成中心化依赖，失去模块自治）

正确的思路是：模块只暴露契约（接口/注解/工厂方法），隐藏实现；对象传递走定义好的通道（服务、工厂、回调），module-info 是这个通道的“路标”而非“运输车”。