| | É. Tanter, “Execution levels for aspect-oriented programming,” Proceedings of the 9th International Conference on Aspect-Oriented Software Development, Rennes and Saint-Malo, France: ACM, 2010, pp. 37-48. DOI = http://portal.acm.org/citation.cfm?doid=1739230.1739236
Robin's Review
Problem |
|
>
> | This paper focuses on a common pitfall in AOP languages built on pointcuts and advice: aspects whose pointcuts are matched in their own advice, leading to infinite loops or recursion in advice weavers or the code they produce. While identified as a fundamental issue in AOP, the recent addition of pointcuts that can invoke code themselves exacerbates the problem. The paper describes and critiques several common solutions to the problem, including using control-flow pointcuts to exclude advice execution and adding extra primitives to the language to hide execution join points from weaving. |
| | Contributions |
|
>
> | This paper claims to provide a solution to infinite regression in the form of "execution levels", wherein each instant in execution (base or advice) is associated with an unbounded number of discrete ordered levels. Advice is declared to only apply to the level immediately below the level it is defined at, and by default advice is declared at the level immediately above the code that declares it, with the net effect that advice normally does not advise other advice code. Shifting operators are provided to allow code to explicitly override this behaviour, in order to selectively restore the conflation of base and advice code for situations where this is the desired behaviour.
The author provides an abstract description of this extension, and concrete semantics for an application of it to AspectScheme, an AOP language based on Scheme. |
| | Weaknesses |
|
>
> |
- The examples of infinite regression described early on in the paper all seem to have better possible solutions when considered individually:
- 2.1 (The Activity aspect that applies unintentionally to the Point#toString method): the key issue here is that the toString() method is incorrectly considered relevant to this aspect: simply excluding the toString() method from the relevant pointcut would be a simpler and more reliable solution. This reflects the fact that code has a lot of constraints and implicit rules that advice needs to be aware of in order to function correctly in general.
- 2.2 (Pointcut loops): I'm personally very uncomfortable with pointcut expressions including normal code, and would much rather not include pointcuts such as AspectJ's "if". There is also evidence that this is confusing for developers: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg06195.html. Dealing with join points inside pointcut expressions feels like a superficial improvement on a much deeper problem.
- 2.3 (Control-flow exclusion not working with "around" advice): I would call this a bug in the "adviceexecution" pointcut, as the "proceed()" syntax is not a regular method call. It would be much more consistent to exclude code triggered by resuming from advice code from this pointcut.
- 2.4 (Visibility of aspects): interaction of aspects does indeed have to be controlled carefully, but aspect dependency management is part of languages like AspectJ already. The complexity of this convinces me that a single ordered dimension of visibility isn't adequate for a mature code base.
- 2.5 (Concurrency): again, this issue is avoided if the pointcut is customized to exclude toString() explicitly.
- The assumption that avoiding infinite regression is fundamentally safer is demonstrably false. As illustrated in the paper, unintentional interaction of aspects can lead to immediate failure in the form of infinite recursion, but non-interaction can lead to missing behaviour, which is much harder to identify. A security-related aspect, for example, could fail to track or access-control references to vulnerable functions simply because they have been refactored into aspects!
- The fact that the proposed solution is presented in Scheme notation and semantics makes it difficult to relate the solution back to the examples of the problem from Section 2. This runs deeper than mere reader understanding, in fact: because the solution is given in a language where pointcuts and advice are treated as first-class values, and declaring aspects is performed inline with normal execution rather than statically, I'm not convinced it is actually reasonable to apply execution levels properly to AOP languages like AspectJ.
|
| | Questions |
|
>
> |
- Is infinite regression of advice fundamentally harder to debug, understand and correct than classic infinite recursion or looping in non-AOP code?
- Are there other potential pointcut varieties needed to avoid all cases of infinite regression?
- What was the intended benefit of adding the "if" pointcut to AspectJ, when it should be equivalent to wrapping the advice body in the same if condition?
|
| | Belief |
|
>
> | I believe this paper does a good job of identifying a common difficulty with AOP languages, but misses the mark with its assessment of where the true issue lies. The idea of execution levels is reasonable and well-formed in of itself, but is not a convincing alternative to other solutions not considered in their evaluation, and in my opinion its downsides are worse than the current state of the art. |
| | Nick's Review
Problem |
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.