Java模块化系统（JPMS）不参与注解处理器的加载与可见性控制，其依赖META-INF/services注册和processorpath配置，与module-info.java无关。

Java 模块化系统（JPMS）本身不参与注解处理器的加载与可见性控制。注解处理器在编译期由 javac 调用，其发现和执行机制完全独立于 module-info.java 中的 requires、exports 或 provides 声明。理解这一点是避免常见误区的关键。

---

注解处理器的注册不依赖模块系统

• 注解处理器必须通过传统服务发现机制注册：
  在 JAR 包根路径下提供文件
  META-INF/services/javax.annotation.processing.Processor，
  内容为处理器全限定类名（如 com.example.MyProcessor）。

• javac 在启动时扫描 -processorpath 下所有 JAR，读取该文件并加载类，完全忽略 module-info.class。
  即使你把处理器打包成 JPMS 模块，并在 module-info.java 中写：

  provides javax.annotation.processing.Processor with com.example.MyProcessor;

  这行代码对 javac 没有任何作用——它只对运行时 ServiceLoader 有效。

• 所有主流处理器（Lombok、MapStruct、AutoValue、Room）均未使用 module-info.java，而是兼容 JDK 8+ 的扁平 classpath 模式。

---

编译期“可见性”实际取决于构建配置

真正影响注解处理器能否生效的，是构建工具如何将其纳入编译流程：

立即学习“Java免费学习笔记（深入）”；

• Maven 中必须用 annotationProcessor scope（不能用 compile 或 runtime）：

  

  Miller CSV TSV JSON 数据处理器

  Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。

  下载

  <dependency>
    <groupId>com.example</groupId>
    <artifactId>my-processor</artifactId>
    <version>1.0</version>
    <scope>provided</scope> <!-- 或省略，默认 compile，但需配合 plugin 配置 -->
  </dependency>

  并确保 maven-compiler-plugin 版本 ≥ 3.8，且启用 processor 扫描：

  <configuration>
    <annotationProcessorPaths>
      <path>
        <groupId>com.example</groupId>
        <artifactId>my-processor</artifactId>
        <version>1.0</version>
      </path>
    </annotationProcessorPaths>
  </configuration>

• Gradle 中对应 annotationProcessor 配置项，Kotlin 项目推荐改用 KSP（Kotlin Symbol Processing），它绕过 Java AST 解析，速度更快，且原生支持模块化项目结构。

• 若处理器依赖了其他模块中的注解类型（比如 @DomainEntity 定义在 api-module），则：

  • api-module 必须被 processor 的 classpath 包含（即 processor 的 pom.xml 中声明该依赖）；
  • 但 api-module 自身是否是 JPMS 模块、是否 exports 注解包，只影响注解类能否被处理器成功解析（TypeElement 获取），不影响处理器本身的加载。

---

模块化项目中使用注解处理器的实操要点

• 不要在 module-info.java 里为注解处理器写 requires
  除非你写的不是处理器，而是运行时需要调用该注解逻辑的框架类（比如一个校验器在运行时读取编译期生成的元数据）。处理器自身是编译工具链的一部分，不属于模块图。

• 若你的注解定义在模块 A，处理器在模块 B，而被处理的业务类在模块 C：

  • 模块 A 必须 exports 注解所在的包（如 exports com.example.annotation;），否则模块 B 的处理器无法 getTypeElement("com.example.annotation.DomainEntity")；
  • 模块 C 不需要 requires 模块 B（处理器），只需要确保编译时 processorpath 包含 B 的 JAR 即可。

• 验证是否生效最直接的方式：

  • 查看编译日志是否有 Processing @DomainEntity 类似输出；
  • 检查 target/generated-sources/annotations/（Maven）或 build/generated/source/kapt/（Kotlin）下是否生成了预期文件；
  • 用 javap -s 看目标类字节码是否包含新增方法（如果是字节码增强型，而非源码生成型）。

---

总结一句话

注解处理器的“模块可见性”，本质是构建路径可见性，不是 JPMS 可见性。它靠 processorpath 和 META-INF/services 工作，与 module-info.java 无关。真正要管的，是注解类型所在模块是否导出、生成代码是否被正确注入、以及构建配置是否让处理器真正跑起来。