代码分析工具和类型间声明答案

【问题标题】：Code Analysis Tools and Inter-Type-Declarations代码分析工具和类型间声明
【发布时间】：2011-01-14 17:29:07
【问题描述】：

我有一个由 Spring Roo 生成的 maven 项目，并使用多种工具（checkstyle、pmd 等）来收集有关我的项目的信息。（即我为此使用codehaus' sonar）

Roo makes heavy use of AspectJ Inter Type Declarations (ITD) 用于区分持久性、javabeans-getter/setter 等问题。

这些 ITD 是在编译时编入的，因此 checkstyle 和 pmd 等工具（在源代码级别工作）有很多误报。

我目前看到的唯一解决方案是停用对使用 ITD 的类的检查。

有更好的想法吗？

【问题讨论】：

我已经用谷歌搜索了一段时间，还与 SCA 工具的工具供应商进行了交谈。似乎这仍然是一个小众问题:-(
我们也使用 Roo 和 Sonar，所以我很想看看这个问题的答案......
啊，不成为唯一的感觉真好。所以你知道我说的问题吗？
您的问题似乎是您要求 SCA 工具处理他们不理解的语言的源代码，即“您的目标语言 + 方面”。为什么不在经过方面处理的代码而不是原始代码上运行分析工具？那么类型信息就是正确的，工具正在处理的语言就是它们所期望的。
这正是我正在谈论的解决方法。对我来说，问题不是如果，而是应该怎么做。对于我的特殊情况，roo 团队已经在考虑这个问题，所以我有希望:-)

标签： java maven-2 aspectj spring-roo static-code-analysis

【解决方案1】：

这个答案现在对您没有帮助，但希望它会引起您的兴趣，因为它有望在不久的将来解决您的问题。我不知道你是否知道 IntelliJ IDEA - JetBrains 的 Java IDE，但是已经在这个方向上进行了工作，这里是你可能想要关注的专门问题的链接：http://youtrack.jetbrains.net/issue/IDEA-26959。只需在上面设置一个手表 - 并在实现该功能时收到通知。 IntelliJ IDEA 提供了非常强大的 SCA。因此，ITD 支持也应该是高质量的。

【讨论】：

感谢您的提示。尽管我希望看到工具供应商方面的意识不断提高，但我更喜欢可以从 maven2 使用的解决方案。我希望能够在 CI 服务器等无头环境中运行我的 SCA。所以我负担不起取决于特定的 IDE。
可以从 maven 和 CI 服务器（如 TeamCity）运行代码检查，因为 IntelliJ IDEA 的其他分析功能已经这样做了。它们可以独立于 IDE 使用，并在服务器端远程运行。

【解决方案2】：

怀疑这将是一个更长的“利基问题” :-) 希望工具供应商会考虑必要的增强功能。

【讨论】：

哇。罗德约翰逊的回答。我很荣幸 :-) 我询问了一些商业工具供应商，但仍在等待答复。但如果我没记错的话，两个主要的 Aspect-J 开发人员也在 springsource 工作，也许他们有一个聪明的解决方法的想法？

【解决方案3】：

FindBugs 和 Cobertura 都不能在源代码级别上工作，而是在字节码级别上工作。因此，您应该在编译时（例如使用 maven 的 AspectJ 插件）而不是在加载时静态地挥动您的方面（这也将改善应用程序启动时间），然后在结果字节码上运行静态分析工具。

【讨论】：

您好，我查过了。你是对的。我得到的大多数误报来自 pmd 和 checkstyle，它们都在源代码级别工作。然而问题仍然存在：您无法分析您看不到的代码。

【解决方案4】：

如果要在将切面编入代码后对源代码进行推理，则应将切面编入源代码而不是二进制代码。

许多方面编织器进行二进制代码编织是因为他们无法访问编译器前端生成的信息（符号表、名称、类型、表达式类型...）。所以，技巧是，使用编译器生成的虚拟机代码（这个噱头基本上只适用于 VM 指令集，如 .net IL 和 java 类代码），通常很容易解码（漂亮的常规指令集）装饰符号表信息。

但是，如果您无法推断这种编织过程的二进制结果，那么您无法确定编织程序没有错误，这就是 OP 原始问题的重点：“我该怎么做在（有效的）编织源上运行 SCA 工具？”。

您可以通过两种方式解决此问题：

让社区编写处理字节码而不是源代码的 SCA 工具。这可能很难，因为源代码可能包含在编译过程中丢失的信息。
更好的主意： 让切面社区编写切面编织器，对源代码进行操作并生成源代码。这可能很难，因为获得完整的语言前端很困难。

我无法帮助您让社区做出选择。

我可以大力鼓励社区选择第二种方式：我们的DMS Software Reengineering Toolkit。这是一个程序转换系统，它执行以下形式的指令，“如果你看到 this，用 that 替换它”，但尊重语言的语法和语义通过将这些更改实际应用于由全语言前端生成的编译器数据结构。（这是数学中方程代换的软件工程版本）。更改后的数据结构可以重新导出为可编译的源文本，并使用 cmets 完成。

如果您了解转换通常可以做什么，您可以看到aspect weavers are a special case of program transformation systems。所以，这很容易使用 DMS 实现切面编织器，结果是源代码，这意味着您可以应用源代码分析工具。

我怀疑这是否真的解决了短期内分析 Roo 生成代码的 OP 问题：-{

【讨论】：

【解决方案5】：

您能否在 Java 代码中添加特定于工具的注释/cmets 以抑制误报？例如，FindBugs 有自己的 @SuppressWarnings 注解。

【讨论】：

嗯，很有趣。我不知道。尽管这仅适用于每个工具的工具，但它可能是一个起点。
根据文档，您不应该接触 AspectJ 文件。这些文件是由 shell 本身管理的，并且可能会在您安装较新版本的 Roo 时进行升级
我的意思是修改 Java 代码，而不是 ITD；我已经更新了我的答案以更清楚。但作为 Roo 团队的一员，很高兴看到用户知道不要编辑 ITD！ :-)