Let's take two examples that are given in any AOP language, logging and context passing.

AOP takes pride of the fact that it allows "injecting" code at the beginning and at the end of any method (specified using sophisticated "regular expressions"). But does this really qualify as a logging and tracing mechanism? Not really. Any non-academic application has functions with multiple exit points (although this on itself can be called a bad programming practice) with multi-branch logics inside. Typically I would have 5-8 log points with various log levels. The important lines that i wish to log most certainly lie inside the code. Each line prints information on specific objects. Moreover, these messages must be localized using DB (or configuration XML file) and filtered based on the log level that can change at runtime (presumably after an erroneous behaviour is spotted). AspectJ most certainly does not provide any means to do this.

Second, context passing. Now we have a stack of 10 functions and we need to pass additional parameter to the innermost function. Now we have two cases: there are already way too many parameters and we don't want to pass an additional one (this is called not modular in AspectJ tutorial); or we have some class that contains all the arguments and we are too lazy to change it. The second case is obvious - it costs next to nothing to put an additional member to this class without breaking the modularity. The first one is more tricky. If you have already 15-20 parameters for each function, than your coding practices really suck. If you are unwilling to add a parameter to a function that doesn't really need it, but has to pass it to another function that does, you should rethink the design of your functions. In any case, "pushing" a parameter into a code that wasn't designed to handle it is very bad design. Moreover, this forces reading multiple files in order to understand what each function does.

Another examples of AspectJ from the tutorial in short:

• pre and post conditions - should really be a part of the methods (especially in Java where you should be able to read the Javadocs to understand what is the contract and when the exceptions are thrown)
• contract enforcement - covering up for a bad design.
• configuration management - via standard resource bundles, property files and Ant configuration.