This article is intended to be a collection of hints concerning AspectJ. Currently, this list is pretty short, but I'm going to add new hints whenever I stumble into a caveat. You can add to the list yourself: Please feel free to add your own experiences using the comment function.
Don't set a breakpoint on the first line
This example applies to Eclipse without the AJDT plugin. Chances are that AJDT fixes the bug (I didn't verify this). I suspect other IDE suffer from the same bug, but I didn't check this, either.
If you set a breakpoint on the first line of a methods that is woven into an @around or @before aspect, the debugger will stop at the breakpoint twice. Set it at the line below, and the debugger will stop only once. In my particular use case this behavior puzzled me completely because I didn't expect the debugger to stop at all - thus making me believe the weaving mechanism didn't work:
As you can clearly see, this method contains a calculation that takes ages to finish. So I wrote an aspect that calls the method only once; after that, the aspect just returns the value stored in a cache. I knew the calculation had already been stored in the cache, but the debugger stopped at the first line of the method. Even worse, the stack trace window of Eclipse didn't show my aspect. So I concluded that the caching aspect wasn't woven around the method - but this conclusion turned out to be wrong.
The explanation is simple: As you can read in my detailed analysis of the AspectJ byte code, AspectJ adds some code before the first line of the method. Unfortunately, it also duplicates the byte code instruction exhibiting the line number. The Eclipse debugger relies on this byte code instruction to determine when to stop. So AspectJ make it stop twice: the first time just before the aspect is executed, and the second time after calling joinPoint.proceed().
You can see this even without looking at the byte code. Just use the "step into" command of eclipse to dive into the AspectJ implementation of your aspect.