代码分析工具和类型间声明
我有一个由 Spring Roo 生成的 Maven 项目，并使用多种工具（checkstyle、pmd 等）来收集有关我的项目的信息。 （即我为此使用 codehaus 声纳）
Roo 大量使用 AspectJ 内部类型声明 (ITD) 来分离持久性、javabeans-getter/setters 等关注点 这些 ITD 在编译时交织在一起，因此
checkstyle 和 pmd（在源代码级别工作）等工具有很多误报。
我目前看到的唯一解决方案是停用对使用 ITD 的类的检查。
还有更好的想法吗？
I have a maven project generated by Spring Roo and use several tools (checkstyle, pmd etc.) to collect information about my project. (namely I am using codehaus' sonar for this)
Roo makes heavy use of AspectJ Inter Type Declarations (ITD) to seperate concerns like persistence, javabeans-getter/setters etc.
These ITDs are woven in at compile-time so tools like checkstyle and pmd (who work on source-level) have a lot of false positives.
The only solution I currently see, is to deactivate checks for Classes that use ITDs.
Any better ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这个答案现在对您没有帮助，但希望它能引起您的兴趣，因为它承诺在不久的将来解决您的问题。
我不知道您是否了解 JetBrains 的 IntelliJ IDEA - Java IDE，但已经在这方面开展了工作，这里是您可能想要关注的专用问题的链接：http://youtrack.jetbrains.net/issue/IDEA-26959。只需在其上设置一个手表 - 并在该功能实施时收到通知。
IntelliJ IDEA 提供了非常强大的 SCA。因此，ITD 支持也应该是高质量的。
This answer would not help you right now, but hopefully it can be of interest for you, as it promises solution for your problem in a near future.
I don't know whether you know IntelliJ IDEA - Java IDE from JetBrains, but there is already work being done in this direction, and here is the link to the dedicated issue that you might want to follow: http://youtrack.jetbrains.net/issue/IDEA-26959. Just set a watch on it - and get notified when the feature is implemented.
IntelliJ IDEA provides really powerful SCA. So, ITD support should be of a high quality as well.
怀疑这将是一个“利基问题”更长的时间:-)
希望工具供应商能够考虑必要的增强功能。
Doubt it will be a "niche problem" for much longer :-)
Hopefully the tool vendors will look at the necessary enhancements.
FindBugs 和 Cobertura 都不能在源代码级别上工作，而是在字节码级别上工作。因此，您应该在编译时（例如使用 maven 的 AspectJ 插件）而不是在加载时静态地波动方面（这也会提高应用程序启动时间），然后对结果字节码运行静态分析工具。
Both FindBugs and Cobertura do NOT work on the source level, but on the bytecode level. So, you should wave in your aspects statically (that would also improve application start time) at the compile time (e.g. using maven's AspectJ plugin) and not at the load time and then run static analysis tools on the result bytecode.
如果您想在将方面编织到代码中后对源代码进行推理，则应该将方面编织到源代码而不是二进制代码中。
许多方面编织器进行二进制代码编织，因为它们无法访问编译器前端生成的信息（符号表、名称、类型、表达式类型……）。所以，破解方法是，使用编译器生成的虚拟机代码（这个特技基本上只适用于 VM 指令集，如 .net IL 和 java 类代码），通常很容易解码（很好的常规指令集）符号表信息。
但是，如果您无法推理这种编织过程的二进制结果，那么您就无法确定编织程序没有错误，这就是OP最初问题的要点：“我如何运行SCA工具关于（有效）编织源？”。
您可以通过两种方式解决此问题：
我无法帮助你让社区做出选择。
我可以大力鼓励帮助社区选择第二种方式：我们的 DMS 软件重组工具包< /a>.这是一个程序转换系统，执行以下形式的指令：“如果您看到this，请将其替换为that”，但尊重语言的语法和语义通过将此类更改实际应用于完整语言前端生成的编译器数据结构。 （这是数学中方程替换的软件工程版本）。更改后的数据结构可以重新导出为可编译的源文本，并附有注释。
如果您了解转换通常可以做什么，您可以看到 方面编织器是一个特例程序转换系统。所以，很容易
使用DMS实现切面编织器，结果是源代码，这意味着
您可以应用源代码分析工具。
我怀疑这实际上能在短期内解决分析 Roo 生成的代码的 OP 问题：-{
If you want to reason about the source code after aspects have been woven into the code, you should weave the aspects into the source code rather than the binary code.
Many aspect weavers do binary-code weaving because they don't have access to the information (symbol table, names, types, expression types,...) produced by a compiler front end. So, the hack is, use the virtual machine code produced by the compiler (this stunt basically only works for VM instruction sets like the .net IL and java class codes) which often is easy to decode (nice, regular instruction set) decorated with symbol table information.
But if you can't reason about the binary results of such a weaving process, then you can't be sure than the woven program isn't buggy, which is the point of the OP's original question: "How do I run SCA tools on the (effective) woven source?".
You can fix this two ways:
I can't help you make the community make a choice.
I can offer strong encouragement to help the community choose the second way: our DMS Software Reengineering Toolkit. This is a program transformation system that carries out directives of the form of, "if you see this, replace it by that" but honoring the syntax and the semantics of the language by actually applying such changes to compiler data structures produced by full language front ends. (This is the software engineering version of equational substitution in mathematics). The changed data structures can be re-exported as compilable source text, complete with comments.
If you understand what transformations can do in general, you can see that aspect weavers are a special case of program transformation systems. So, it is easy
to implement aspect weavers using DMS, and the results are source code, which means
you can apply the source-code analysis tools.
I doubt this actually solves the OPs problem of analyzing Roo-generated code in the short term :-{
您能否在 Java 代码中添加特定于工具的注释/注释来抑制误报？例如，FindBugs 有自己的 @SuppressWarnings 注释。
Could you add tool-specific annotations/comments to the Java code to suppress the false positives? For example, FindBugs has its own @SuppressWarnings annotation.