java - Java 注释处理 - 目的和示例

Question

即使度过了愉快的时光，我也无法理解注释处理的目的。

我理解为什么运行时需要注释，我能想到的最简单的例子是：

1. 更换标记接口。
2. 替换一种类型的市场属性（例如瞬态）
3. 一般来说，可以在运行时完成的任何用处。

但不幸的是，我无法理解在编译时使用注释的任何实际示例/原因（JDK 提供的默认注释除外，例如 @Override 等）。

我不明白使用注释处理器“生成代码”的目的/需要是什么。

编辑：Javadoc/Custom Java doc 是我可以认为是使用注释处理器的一个实用程序。

Answer 1

这可以用于各种事情。

两个简单的例子

1. 隆博克项目。厌倦了编写成千上万的 getter 和 setter？为什么不让注释处理器在编译时完成它。
2. 奥普。您可以使用AspectJ 之类的东西来编织依赖于注释的代码。这将在编译后完成，但作为编译过程的一部分。例如， Spring AOP@Transactional结合 AspectJ使用注解来围绕标有注解的方法编织事务代码。

还有许多其他用途，但它们通常分为两类

1. 减少样板代码。
2. 对于横切关注点。

Answer 2

注释处理环境有两个主要用途——分析和代码生成。

该分析允许您扩展 java 编译器的功能，在编译程序元素时对其进行分析，可能会添加额外的约束、验证以及报告错误和违反这些约束的警告。

代码生成允许您从现有手写代码中的信号生成额外的补充代码，主要（但不排他地）与注释无关。

一些例子包括Dagger，这是一个用于编译时分析依赖注入的系统，它报告通常在运行时而不是在代码编译期间发现的错误和警告。Dagger 还生成通常通过反射或手写胶水代码完成的所有代码，提供显着的性能优势（在某些情况下）以及可用于逐步调试等的基础架构代码。

另一个例子是检查器框架，它评估对您的代码的各种检查，包括空安全性等。

第三个示例是Auto-Value，旨在使小值类型几乎可以轻松编写。

注释处理环境绝对不适合的一件事是现有代码的突变，或当前正在编译的代码的修改。虽然有些项目这样做，但它们实际上并没有使用注解处理器 API，而是强制转换为内部编译器类型来这样做。虽然这显然是可能的，但它可能很脆弱，并且可能无法在不同版本或编译器之间可靠地工作，需要针对每个版本和编译器供应商进行自定义处理。