Section 12.3. DISCUSSION

12.3. DISCUSSION

In this section, we discuss advantages and drawbacks of the use of reflection to support AOP.

12.3.1. Flexibility

Many reflective systems make meta-objects exist during runtime. This is the case in MetaclassTalk and other MOPs [32, 33, 39, 42]. One of the main benefits of this approach is flexibility: the set of meta-objects controlling a base object can be changed dynamically at runtime. Since aspects are represented using meta-objects, it becomes possible to weave or unweave aspects dynamically [1, 9, 11, 22, 33].

Weaving and unweaving aspects dynamically is an interesting feature for applications dealing with problems such as pervasive or automatic computing and unplanned or context-aware evolution. For example, in the context of critical systems that should not be stopped for maintenance or unplanned evolution, new aspects can be added, and existing ones can be removed or upgraded dynamically.

Quality of Service (QoS) is another benefit of flexibility provided by dynamic weaving [15]. QoS is mandatory in application domains where resources are constrained and variable in time (e.g., in embedded systems). Aspects can be (un)weaved at runtime according to the execution conditions [9]. For example, the bandwidth of a wireless connection on a PDA can undergo variations, which must be taken into account to provide a correct QoS [10]. A typical PDA has limited CPU power and memory size, except when it is docked at a desktop. When the network bandwidth is high, the remote communication aspect should save CPU and memory. But when the bandwidth decreases under some threshold, QoS requires replacing the previous aspect. The new remote communication aspect should sacrifice some CPU and memory for caching.

Concretely, remote communication requires having some base objects on the PDA that act as proxies for some remote objects. This behavior is introduced by means of some meta-objects that should be replaced according to the network load. When the bandwidth decreases, a meta-object that makes some base object behave as a plain proxy should be replaced by another one that makes our base object behave as a proxy with cache.

12.3.2. Performance

Flexibility is an advantage of reflection, but its cost is a non-negligible overhead. Indeed, meta-objects act like interpreters. This difficulty is compounded, because in a reflective system, meta-objects can be controlled by some meta-meta-objects.

Various approaches exist to deal with this overhead. One possible solution is to "merge" base and meta-levels at compile time or load time. This is done in OpenC++ 2.0 [7] and OpenJava [8]. This approach, from which AspectJ technology was derived [40], suppresses any "indirection" by flattening the reflective tower. The program is transformed so as to have only one level of objects. However, while this considerably speeds computing, it detracts from flexibility.

Another approach, adopted by Iguana [20, 34] and Reflex [38, 39], consists of restricting the activity of meta-objects to just those places where it is required. This partial reflection makes it possible to limit the overhead to only cases where some special meta-processing is required. However, flexibility is restricted to planned scenarios, and unplanned evolution is not possible. Indeed, meta-objects' capabilities are defined statically and cannot be changed at runtime.

An alternative solution consists of using partial evaluation [5, 37]. This approach promises to keep the flexibility of reflection while drastically reducing performance overhead. Roughly, the idea behind this approach is to assume that meta-objects will not change, and to generate an optimized version of application code under this assumption. This optimized code is run instead of the original code. When the meta-objects change, the optimized code is regenerated.

12.3.3. Complexity

Reflection is one powerful tool for reaching the goal of AOP [27]. Indeed, reflection opens up the programming language and makes it extensible and adaptable. However, reflection has been criticized for its complexity. The underlying concepts tend to be hard to learn and may make programs difficult to understand [12].

Nevertheless, we believe that this complexity can be at least partially hidden. Aspect developers can be provided some aspect-specific (i.e., domain-specific) language that compiles into a reflective language. The aspect-specific language eases expressing aspects while restricting the access to available reflective facilities.

12.3.4. Tooling

One of the issues in building programs using AOP is the lack of appropriate development tools. This is particularly true for debugging. The difficulty of building such tools is among the reasons behind this scarcity. Aspects usually cannot be tested in isolation, and it is difficult to retrieve aspect-specific code by analyzing weaved code.

Reflection provides the benefit of using existing development tools. Aspects can be expressed in terms of classes of meta-objects, whose code can be viewed and edited using class browsers. Testing and debugging can also be done using existing tools. Debugging is made easier since meta-objects aspects remain decoupled one from another. Indeed, each aspect is represented by a set of meta-objects that can be distinguished from other (meta-) objects even after weaving. One can argue that these tools are rather "low-level" and do not suit aspects. However, (1) they are a first answer to the tooling issue, and (2) they can be extended (especially by means of reflection) to better support aspect development.

12.3.5. Reuse

Software reuse is one of the holy grails of software engineering. In order to reuse aspects in different applications, aspects should be generic. That is, the definition of an aspect should not explicitly reference application components. However, weaving requires linking aspects to application components. This is somewhat contradictory with aspect genericity.

By expressing aspects using meta-objects, reflection brings to AOP reuse solutions provided by object-oriented programming (e.g., inheritance). One can easily build new aspects using new meta-object classes that inherit from existing meta-object classes. Furthermore, meta-objects classes can easily be made generic (that is, independent of any application). Indeed, only configuration scripts that link meta-objects to base objects need to be application-specific.