Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] AspectJ and code coverage? 
Hi Andy,
sorry, I completely missed this mail of yours.
It would be an improvement, a low priority one, to review how AspectJ assign source/line number attributes to the code it inlines in classes. This affects not only Cobertura (and any other coverage) reports, but also debugging and stack traces. I can see from the archives that this has been a subject many times.
Having SMAP support would be great, it would help debugging and stack traces a lot. I don't know if coverage tools are using SMAP, but in that case it would not be AspectJ business sine SMAP is a public JSR.
AspectJ inlines some boilerplate code, for example calls to "hasAspect", and calls to closures, in some specific lines : * Aspect initialization, closures code, "proceed" methods, are placed on line 1 of the aspect source. * Calls to aspectOf() for before advices are placed on the first line of a method. * Calls to aspectOf() for around advices are placed on the line before the first line of a method (no matter inlining or not) .. (only if the method has more than one line?). * Inlined around advices keep the advice line number even if they are in the target java file. 

This cause some confusion sometimes :
* Cobertura see instructions on line 1
* Cobertura see instructions in places in the file which are empty lines, or comment, or closing "}". (around advices) * The user places a breakpoint on the first line of a method, and when the debugger stops there it may be in a chain for around advices.
The third problem, even if not related to the subject of this message, is the most annoying one. Even with "no inline" a break point on the first line of a method will cause random breaks.
I'm so used to this that I place the breakpoint on the second line of the method, or even place a dummy line as the first line of the method just to avoid these.
Given the limited support of the JVM for such scenarios (only one SourceFile attribute), excluding SMAP, I don't know of a way to avoid this from happening.
However, to partially solve both the coverage report and the debug issue, maybe the different scenarios could be reduced to one, with one of the following strategies : A) Every instruction added by AspectJ resides always on line 1 of the target file. So, if you see instructions in this zone of a coverage file, or if you end at the first line of a file during debug , or you see "line 1" in a stacktrace ... don't worry it's AspectJ boilerplate code. Also, break point on first line of a method will work as expected. B) Instructions around/before/after methods are placed on the line "before" the first line of the method, or on the line "after" the last line of the method. Break point on first line of method will work as expected, and coverage report on "dummy" lines of code (like the method declaration, or the closing "}") as well as stepping into them during debug, can be considered spurious cause it is in reality AspectJ boilerplate code.
Currently part of A and part of B are in place, while I think that inlined around advice, being unable to refer to the original .aj file, should still use a line number that does not gets confused with target .java file lines when seen in stack traces, or while debugging or running coverage on a code compiled without the "no inline" option.
Solution B is currently used by around advices, where the call to the closure is marked as being on the line before the actual first line of the method, but it does not happen always. For example, a series of single line methods (single line including method declaration and body) all with an around advice, does not move the line to the previous one (which is great, cause otherwise I could see coverage/stacktraces referring to method A while in fact method B was executing).
Cobertura (and Clover, and I suppose also Emma) supports ignores, so (some) calls to (some) AspectJ boilerplate code could be ignored using some regular expressions, as well as closures can be ignored completely. 


Simone


Andy Clement wrote:

Hi Simone,

Regarding:


Since AspectJ inlines a few calls inside methods using "line 1" of the target class file, or the first line of the method,
you'll see cobertura reporting a lot of hits on this lines, even if they does not contain any apparently useful code.


Do you think there is something better we can do to produce nicer
reports? (I'd probably use synthetics, or fix up the lines to
something more appropriate, or get that SMAP thing going that we've
put off for so long)

Andy

2009/11/30 Simone Gianni <simoneg@xxxxxxxxxx>:

Hi Wim,
I'm using Maven2 + AspectJ + Cobertura successfully, but there are a few
caveats.

I'm currently weaving first and then instrumenting with cobertura. If I
remember correctly, I'm cobertura-instrumenting the entire jar. I could do
this cause in our setup coverage reports are executed in a separate step,
when generating the project site. Since AspectJ inlines a few calls inside
methods using "line 1" of the target class file, or the first line of the
method, you'll see cobertura reporting a lot of hits on this lines, even if
they does not contain any apparently useful code. This may confuse who is
used to cobertura reports and not aware of AspectJ internals, but can be
interpreted as useful informations cause you may understand how many
instructions are executed because of AspectJ aspect lookup.

I also set up a "load time cobertura instrumentation", that goes in pair
with load time weaving, but in that case if an entire class does not get
loaded, cobertura knows nothing about it, which alters the global coverage
measurements, so I dropped it.

If you have a specific error, I can try to investigate it.

Simone



Wim Deblauwe wrote:

Hi,

is there anybody who is using AspectJ with a code coverage tool. We are
using Cobertura and Maven2, but that does not work when you start to add an
aspect to your code and you need to use the ajc compiler. I just checked
with Atlassian and Clover cannot seem to manage it according to them.
Anybody knows a workaround? I don't want to have code coverage on the
aspect, I just don't want to loose the coverage on my regular java classes.

regards,

Wim
------------------------------------------------------------------------

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users


--
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users



--
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/

Back to the top