Java中注释处理的缺点是什么？

Question

我正在考虑启动一个项目，该项目用于使用注释在Java中生成代码（我将不详细介绍，因为这并不真正相关）。我想知道这个项目的有效性和有用性，让我印象深刻的是对注释处理器工具（apt）的依赖

我想知道的是，在Java中使用注释处理的缺点是什么，因为我不能从经验中说出来

这些可能是任何东西，包括：

• 编写处理器时很难进行TDD
• 在构建系统中包含处理是很困难的
• 处理需要很长时间，而且很难让它快速运行
• 在IDE中使用注释需要每个都有一个插件，以使其在报告错误时表现相同

这些只是例子，不是我的观点。我正在研究这些是否属实（包括问这个问题；-））

我确信一定有缺点（例如，Qi4J特别列出了不使用预处理器作为优势），但我没有经验来说明它们是什么

使用注释处理的唯一合理替代方案可能是为相关IDE创建插件来生成代码（这与重写/实现方法功能大致类似，该功能将生成所有没有方法体的签名）。然而，在每次代码的相关部分发生更改时，都必须重复该步骤，据我所知，注释处理不会重复

关于给定的示例中大量的注释，我不认为需要这样的使用，对于任何给定的类，可能都需要少量注释。当然，这并不能阻止它被滥用

Answer 1

我认为如果annotation processor肯定会使用Java 6版本的API。这是一个将在未来得到支持的方案。Java5API仍在非官方的com中。太阳xyz名称空间

我认为在不久的将来，我们将看到注释处理器API的更多用途。例如，Hibernate正在为新的JPA2查询相关静态元模型功能开发处理器。他们还开发了一个处理器，用于验证Bean验证注释。因此，注释处理将继续存在

工具集成还可以。主流IDE的最新版本包含配置注释处理器并将其集成到构建过程中的选项。主流构建工具也支持注释处理，maven仍然会带来一些麻烦

但是我发现了一个大问题。所有测试都是间接的，以某种方式验证注释处理的最终结果。我无法编写任何简单的单元测试，这些测试只能断言在TypeMirrors或其他基于反射的类上工作的简单方法。问题是不能在处理器编译周期之外实例化这些类型的类。我认为Sun在设计API时并没有真正考虑可测试性