Bridging Java and AspectJ through explicit join points

Abstract

Through AspectJ, aspect-oriented programming (AOP) is becoming of increasing interest and availability to Java programmers as it matures as a methodology for improved software modularity via the separation of cross-cutting concerns. AOP proponents often advocate a development strategy where Java programmers write the main application, ignoring cross-cutting concerns, and then AspectJ programmers, domain experts in their specific concerns, weave in the logic for these more specialized cross-cutting concerns. However, several authors have recently debated the merits of this strategy by empirically showing certain drawbacks. The proposed solutions paint a different development strategy where base code and aspect programmers are aware of each other (to varying degrees) and interactions between cross-cutting concerns are planned for early on.Herein we explore new possibilities in the language design space that open up when the base code is aware of crosscutting aspects. Using our insights from this exploration we concretize these new possibilities by extending AspectJ with concise yet powerful constructs, while maintaining full backwards compatibility. These new constructs allow base code and aspects to cooperate in ways that were previously not possible: arbitrary blocks of code can be advised, advice can be explicitly parameterized, base code can guide aspects in where to apply advice, and aspects can statically enforce new constraints upon the base code that they advise. These new techniques allow aspect modularity and program safety to increase. We illustrate the value of our extensions through an example based on transactions.

Where the Truth Lies: AOP and Its Impact on Software Modularity

“…try-catch blocks in loops, etc.) that AspectJ can capture [21]. As discussed in [8], these new methods are not part of the implementation of the exception-handling concern but a direct consequence of using aspects to implement this concern.…”

“…In the first group [8,16,19,25], new kinds of coupling introduced by pointcuts are not considered at all. In the second group [21,42], the coupling introduced by a pointcut is considered only if a module is explicitly named by the pointcut expression.…”

“…In their study [21], they calculated two coupling metrics, namely CBM and CIM. However, since CBM and CIM are not simply additive, the results are difficult to interpret.…”

An Empirical Assessment of the Impact of Aspect-Oriented Programming on Software Modularity

“…This tool implements the metric suite proposed by Ceccato & Tonella [7]. Although several researchers have used AOPmetrics [16], [21], they are not aware of its bugs. First of all, the implementation of CDA metric does not count modules coupled by pointcuts.…”

“…The other studies either do not consider the coupling introduced by pointcuts at all [21], [10], [12] or consider it only if a module is explicitly named by the pointcut expression [32], [16]. No matter which of these two categories the study belongs to, the measured coupling is underestimated.…”