如何让 Eclipse 和 Gradle 在移除注解时也触发注解处理器-java教程-PHP中文网

本文详解如何配置 Java 注解处理器，使其在 Eclipse（配合 Buildship）和 Gradle 构建中均能响应注解的移除操作，通过支持通配符 *、重写 process() 逻辑与分离文件写入阶段，实现增量式元数据文件（如 META-INF/annotations/）的准确更新。

本文详解如何配置 java 注解处理器，使其在 eclipse（配合 buildship）和 gradle 构建中均能响应注解的**移除操作**，通过支持通配符 `*`、重写 `process()` 逻辑与分离文件写入阶段，实现增量式元数据文件（如 `meta-inf/annotations/`）的准确更新。

在标准 Java 注解处理机制中，Processor.process(...) 仅在存在被处理注解的源元素时被调用。因此，当开发者从某个类上删除注解后，Eclipse（尤其使用 Buildship 的 Gradle 项目）通常不会触发注解处理器——因为该轮处理中 annotations 集合为空，roundEnv.getElementsAnnotatedWith(...) 返回空集，导致旧条目无法清理，元数据文件（如 META-INF/annotations/YourAnnotation）长期残留过期类名。

根本解法在于：让处理器主动“观察所有类”，而非被动等待特定注解出现。这需满足三个关键条件：

声明支持通配符注解类型：
@SupportedAnnotationTypes({"*"})（或在 getSupportedAnnotationTypes() 中返回 Set.of("*")），告知编译器/IDE 该处理器需参与每一轮处理，即使当前轮无匹配注解。
在每轮 process() 中执行“全量感知 + 增量裁剪”逻辑：

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

下载
- 非终轮（!roundEnv.processingOver()）：扫描当前轮中所有被标注的类，并收集其全限定名；
- 终轮（roundEnv.processingOver()）：统一执行文件写入——基于历史文件内容 + 当前有效类集合，剔除已移除注解的类，写入最新有序列表。
统一输出位置与健壮的旧文件读取逻辑：
使用 StandardLocation.CLASS_OUTPUT（而非 SOURCE_OUTPUT）作为资源输出位置，确保 Eclipse 和 Gradle 构建行为一致；同时增强 openPreviousFile 对空白/缺失文件的容错能力。

以下是生产就绪的处理器核心结构（兼容 Eclipse + Gradle）：

@SupportedAnnotationTypes({"*"})
@SupportedSourceVersion(SourceVersion.RELEASE_11)
@AutoService(Processor.class)
public class AnnotationTextDump extends AbstractProcessor {
  private List<annotationwriter> writers = null;

  @Override
  public Set<string> getSupportedAnnotationTypes() {
    return Set.of("*");
  }

  @Override
  public boolean process(Set extends TypeElement> annotations, RoundEnvironment roundEnv) {
    if (writers == null) {
      // 显式声明需监控的注解类型（避免反射风险）
      writers = List.of(
          new AnnotationWriter("com.example.MyAnnotation"),
          new AnnotationWriter("com.example.OtherAnnotation")
      );
    }

    if (!roundEnv.processingOver()) {
      // 收集本轮新出现的有效标注类
      for (var writer : writers) {
        writer.collectNewElements(annotations, roundEnv, processingEnv);
      }
    } else {
      // 终轮：合并历史 + 当前，写入最终文件
      for (var writer : writers) {
        writer.flushToOutput(processingEnv);
      }
    }
    return false;
  }
}

class AnnotationWriter {
  private final String annotationName;
  private final Set<string> currentClasses = new LinkedHashSet();
  private List<string> previousClasses = Collections.emptyList();

  AnnotationWriter(String annotationName) {
    this.annotationName = annotationName;
  }

  void collectNewElements(Set extends TypeElement> annotations,
                          RoundEnvironment roundEnv,
                          ProcessingEnvironment processingEnv) {
    for (TypeElement anno : annotations) {
      if (anno.getQualifiedName().contentEquals(annotationName)) {
        roundEnv.getElementsAnnotatedWith(anno).forEach(element -> {
          String fqn = getFullyQualifiedName(element, processingEnv);
          currentClasses.add(fqn);
        });
      }
    }
  }

  void flushToOutput(ProcessingEnvironment processingEnv) {
    try {
      String fileName = "META-INF/annotations/" + annotationName;
      previousClasses = loadPreviousClasses(fileName, processingEnv);

      // 合并：保留仍被标注的旧类 + 本轮新增类
      Set<string> merged = new LinkedHashSet(previousClasses);
      merged.addAll(currentClasses);

      // 过滤：仅保留当前仍带该注解的类（处理删除场景）
      merged.removeIf(clazz -> !isClassStillAnnotated(clazz, annotationName, processingEnv));

      // 写入排序后结果
      FileObject resource = processingEnv.getFiler()
          .createResource(StandardLocation.CLASS_OUTPUT, "", fileName);
      try (PrintWriter out = new PrintWriter(resource.openWriter())) {
        merged.stream().sorted().forEach(out::println);
      }
    } catch (IOException e) {
      processingEnv.getMessager().printMessage(Diagnostic.Kind.ERROR,
          "Failed to write annotation file for " + annotationName + ": " + e.getMessage());
    }
  }

  private List<string> loadPreviousClasses(String fileName, ProcessingEnvironment processingEnv) {
    try {
      FileObject prev = processingEnv.getFiler()
          .getResource(StandardLocation.CLASS_OUTPUT, "", fileName);
      String content = new String(prev.openInputStream().readAllBytes(), StandardCharsets.UTF_8);
      return Arrays.stream(content.split("\n"))
          .map(String::trim)
          .filter(s -> !s.isEmpty())
          .collect(Collectors.toList());
    } catch (FilerException | IOException e) {
      return Collections.emptyList(); // 文件不存在或读取失败，视为首次构建
    }
  }

  private boolean isClassStillAnnotated(String className, String annotationName,
                                        ProcessingEnvironment processingEnv) {
    TypeElement type = processingEnv.getElementUtils().getTypeElement(className);
    if (type == null) return false;

    return type.getAnnotationMirrors().stream()
        .map(mirror -> mirror.getAnnotationType().asElement())
        .anyMatch(elem -> {
          String qualified = elem.getQualifiedName().toString();
          return qualified.equals(annotationName);
        });
  }

  private String getFullyQualifiedName(Element element, ProcessingEnvironment processingEnv) {
    PackageElement pkg = processingEnv.getElementUtils().getPackageOf(element);
    return pkg.isUnnamed() 
        ? element.getSimpleName().toString() 
        : pkg.getQualifiedName() + "." + element.getSimpleName();
  }
}</string></string></string></string></string></annotationwriter>

✅ 关键注意事项：

不要在非终轮写入文件：若在 !processingOver() 中直接写文件，会导致 Eclipse 增量编译时多次覆盖，且无法清理已删除注解的条目；终轮写入是唯一可靠时机。
使用 CLASS_OUTPUT 而非 SOURCE_OUTPUT：Gradle 默认将生成资源放入 build/classes/java/main（对应 CLASS_OUTPUT），而 Eclipse Buildship 也同步此约定，保证路径一致性。
显式指定监控注解：Set.of("*") 是必要但不充分条件，必须在代码中硬编码需处理的注解全限定名，避免无差别扫描全部类（性能与语义失控）。
异常需转为 Messager 提示：e.printStackTrace() 不会在 Eclipse Problems 视图中显示，应调用 processingEnv.getMessager().printMessage(...) 实现 IDE 可见错误反馈。

通过以上设计，处理器不再依赖“注解出现”这一事件，而是以类为单位持续跟踪其标注状态，真正实现跨 IDE 与构建工具的可靠增量更新——无论是添加、修改还是移除注解，元数据文件始终精准反映当前源码状态。