Donnerstag, 5. April 2007
dynamic code analysis
I had an interesting talk today with Timo Weber about potential usages of static code analysis. I am personal convinced, that there are some usage scenarios, where you want to apply static code analysis, that there are a few usage scenarios where static code analysis is the only way to go, but in most cases this approach is not worth the effort.

Why? Static code analysis does not work if you work with interfaces, java reflection, dependency injection, aspects, runtime code transformation, etc. It does not work either, if you use normal middleware technologies, like ESBs, RMI, CORBA, Webservices. How does your static code analysis tool work with a DSL?
How does it work if you use static typed languages like Java and dynamic typed languages like JRuby, Jython or even Groovy together in the same project?

Even worse: Typical usages of static code analysis do often indicate potential bad smells in the code base. This is often a clear sign that a sensible amount of indirections and abstractions are missing in the code base. It is a clear sign that the code is written against implementations and not against interfaces.

However there are definitively good scenarios available. I just think about the call outline in eclipse.

An interesting idea, would be using dynamic code analysis. But how can you do this?
One approach would be to capture the real call stack of the test base, with some aspects. Writing such an aspect would not be too hard. You may use this aspect even in a life production or test system, if performance is not a time concern.

Another interesting idea is the usage of the AspectJ Reflection API. I blogged about the usage of this API here. However using this API for static code analysis is not the easiest task. The AspectJ Reflection API lacks currently some features.
  • First you need to have the class extend of your application at hand. And Java provides you no way to retrieve the class extend directly out of the box.
  • You have no access to the reflective features of the joinPointStaticPart object, for joinpoints which you have queried through your own dynamic pointcut discriminators.
However, you have a simple approach to ask specific queries about your code base at runtime, without interacting with the bytecode.

Great possibilities, I might give them a try in the future. Please let me know if you have tried the same approach.

... link (0 Kommentare)   ... comment