LogicAJ demonstrates the feasibility of a uniformly generic aspect language design. Its seamless integration of logic meta-variables into the language lets LogicAJ provide much of the expressive power of approaches based on logic meta-programming. However, LogicAJ integrates all the necessary functionality within one uniform aspect language design instead of requiring the programmer to work completely in a logic-based environment (thus failing to use the advantages of object-orientation) or in two different environments at the same time (object-oriented and logic-based).

A Uniformly Generic and Interference-Aware Aspect Language

Uniform genericity lets aspects concisely express effects that may vary depending on the static context of a join point. Moreover, it alleviates the dependency of aspects on names of base entities, making them more reusable and more resilient to changes in base programs.

Interference analysis enables unanticipated joint deployment of independently developed aspects by inferring aspect order automatically. Moreover, it makes aspect semantics independent of the textual ordering of advice declarations and verifies that explicit aspect order specifications are consistent with the aspects you wrote.

Uniform Genericity

Problems

A limitation of AspectJ and other aspect languages is the need to refer explicitly to the names of base program entities (types, classes, methods, etc). This makes aspect code highly vulnerable to changes in base programs. Moreover, in order to express multiple introduction or advice that are similar but not entirely identical one often needs to write code that is largely redundant and differs only in the names of referenced base entities. Such code is difficult to maintain - it replaces base level scattering by intra-aspect scattering. The foremost problem introduced by the dependency on base names is the inability to express aspect effects that are dependent on the static context of the join point. For instance, generic forwarding functionality (as required by many design patterns, like Decorator, Adapter, Wrapper, State, and Strategy) cannot be expressed at all in AspectJ.

Solutions

LogicAJ enables the use of meta-variables for base program elements (fields, methods, parameter lists, argument lists, method bodies, etc.). Meta-variables can be used uniformly in pointcut definitions, introductions and advice. Generic introductions and generic advice can both be subject to prior pointcut evaluation. This enables implementation of aspect effects that can vary depending on the values produced for meta-variables during the evaluation of pointcuts.
Generic introductions make it easy to introduce new types, determine new class members, and vary the code of introduced methods by evaluating predicates. Generic advices replace otherwise redundant or reflective advices and reference methods and fields created by generic introductions.

Applications

Uniform genericity leverages aspect technology by enabling reusable, robust, concise, easy to write, understand, and maintain solutions for problems like

* generic implementations of forwarding-based design patterns (Kniesel, Rho, Hanenberg - RAM-SE04)
* generic implementation of class posing (Rho, Kniesel - IAI-TR-2004-4)
* generic mock objects (Rho, Kniesel - IAI-TR-2004-4)
* variability of aspect effects based on the static context of a join point (Rho, Kniesel - IAI-TR-2004-4)

For more details on the syntax, semantics and use of LogicAJ have a look at our papers.

Interference Analysis

An interference is an undesired interaction between different aspects or between aspects and the base program. Asect-to-aspect interference analysis is indispensible whenever different aspects are deployed jointly:

• If you are sure to know all the deployed aspects, the analysis will ensure that you have not missed some ordering declarations or got them wrong.
• If you don't know all the deployed aspects or are even unaware of some aspects being deployed, you cannot make any sensible ordering declarations. In such cases, the analysis will save your application by inferring orderings for you or telling why this is not possible. For an excellent description of how it can happen that you deploy aspects without even being aware of it, see the AOSD.05 paper "Distributing Classes with Woven Concerns – An Exploration of Potential Fault Scenarios " by Nathan McEachen and Roger Alexander.

Problems

No implemented aspect language we know of supports interference analysis.

In addition, AspectJ makes the sematics of aspects dependent of the textual ordering of advice declarations, in order to compensate for missing analysis capabilities.

Solutions

Using Condor, LogicAJ provides an aspect-to-aspect interference analysis that includes

• the ability to identify a well-defined class of interferences
• the ability to determine an interference-free order of execution, if one exists
• the ability to determine the most suitable weaving algorithm for a given set of aspects

The interference analysis is

• independent of the base programs to which the aspects refer (only aspects need to be analyzed)
• independent of any special annotations of the analyzed aspects

The interference analysis makes aspect semantics independent of the textual ordering of advice declarations within an aspect.

Aspect-level interference analysis is not included in the current release of LogicAJ.

Applications

Our aspect interference analysis leverages aspect technology by making joint deployment of multiple aspects a little bit safer.