Section 15.6. USAGE SCENARIOS

15.6. USAGE SCENARIOS

In this section, we discuss typical application scenarios for JMangler: load-time weaving (Section 15.6.1), run-time weaving (Section 15.6.2), and applications beyond the expressive power of existing high-level AOSD languages (Section 15.6.3).

15.6.1. Load-Time Weaving with JMangler

The straightforward use of JMangler for AOSD development is the implementation of load-time weaving. We talk about load-time weaving if functionality is introduced at load time into an application and activated permanently for the current run of the application.

In the simplest case, the introduced functionality is the intended functionality of an aspect such as tracing behavior. The examples given in the previous section all fall into this category, so we do not go into further details here. Instead, we pick the ObjectTeams project as an interesting large application that uses JMangler for load-time weaving. ObjectTeams [25, 37, 44] is a programming model that builds on research and experience concerning several recent approaches, mostly from the field of aspect-oriented software development.

ObjectTeams/Java adapts classes of the system core at load time using JMangler (with the BCEL weaver). This enables running several ObjectTeams applications with different adaptations to shared modules, although shared modules exist only as a single jar file. No source code is needed, nor are different adapted variants stored in the file system, thus significantly relieving configuration management and deployment.

Thus, on the one hand, ObjectTeams fully exploits the benefits of load-time weaving with JMangler. On the other hand, programmers using ObjectTeams/Java need not know about JMangler since input for transformations is generated by the compiler and invocation of JMangler is encapsulated in the command for starting the Java Virtual Machine.

15.6.2. Run-Time Weaving with JMangler

An advanced use of load-time weaving is to create a system that performs run-time weaving. In such a scenario, it is not the logging code that is weaved at load time but the code that enables dynamic inclusion of logging and other "aspects." This is the way AspectWerkz [2] uses load-time weaving to provide a dynamic, aspect-oriented system with a high, user-friendly abstraction level. In order to be generally applicable, AspectWerkz adopted (and adapted) the generic interception approach of JMangler.

Yet another variant of this idea is described in [42]. Starting from the formal semantics of a core language, which includes method call interception (MCI), different implementation models are examined regarding expressiveness, simplicity, and efficiency. One suggested alternative is to perform static weaving of code that enables dynamic method call interception and to eliminate at load time the hooks that are not relevant for that particular invocation of a program. In this scenario, the load-time transformation is used to unweave code that only slows down the application without providing any functional benefit. Thus, the load-time transformer behaves as an optimizer for the statically weaved code that performs dynamic weaving.

15.6.3. Advanced Features

For the sake of simplicity, ease of use, or avoidance of conceptual problems, AOSD languages abstract away some of the expressive power available at the bytecode level. We discuss here two cases: (1) parametric and (2) fine-grained analysis and transformation.

15.6.3.1 Parametric Introductions and Advices

The logging example in Section 15.5.6 illustrates that one transformer can compactly express interface and code transformations that are parametric with respect to the exact name of the manipulated entities. The italic style of the method name m (see Section 15.5.6) indicates that this is a variable ranging over the names of all methods that fulfill the conditions for being logged. Correspondingly, the name m_log is a template for names of logging methods to be created. For instance, if the transformer determines at runtime that the methods meth₁, . . . , meth_n should be logged, the template expands to meth₁_log, . . . , meth_n_log.

In AspectJ terminology, our logging example expresses a possibly infinite number of consistent "introductions" and "advices" in one single transformer. This is impossible in AspectJ, which supports only a limited form of parametric names in pointcuts but does not support parametric names in introductions and advices. Put differently, AspectJ can perform wildcard matching of existing names, but it offers no mechanism to create new names that depend on the matched ones. Instead, one has to know statically all names of methods to be logged and write the same introduction code (up to names) for each and every method.

The step from AspectJ's wildcard substitution to "parametric aspects" is a significant change in expressiveness [23]. Moving from statically known names to name variables means making the step from a closed to an open world. This results in extended applicability and expressiveness but also raises additional interference problems, as illustrated by the logging example in Section 15.5.6. The lack of mechanisms for dealing with aspect interference in open worlds is one important reason that prevents many aspect systems from offering parametric transformations.

Disregarding aspect interference, ComposeJ [45] could support a similar functionality by means of meta filters [6]. However, meta filters are not yet implemented. For Hyper/J [39, 40], parametricity seems to be difficult to achieve, due to its declarative completeness requirement (every name referred to must be declared in the referring module).

It seems that the only aspect systems that already provide parametric introductions and advices are systems based on logic metaprogramming, such as TyRuBa [13, 14] and SOUL [41]. An interesting new contribution in this context is the concept of "parametric introductions" in Sally [23]. It is interesting to note that these systems are similar to JMangler in that the backtracking mechanism of logic programming is another way of implementing fixed point iteration.

15.6.3.2 Code Coverage

The common abstraction supported by AOSD languages is interception of variable accesses and method calls. In [19], Filman and Havelund consider the ability to "intercept" finer-grained structures as a desirable improvement to aspect languages. In this section, we give an example application where "interception" at the level of individual statements or individual lines of code is essential: code coverage.

Code coverage is a measure for the percentage of a program exercised ("covered") by the tests run on that program. Coverage is reported on the basis of metrics. For instance, statement coverage reports the percentage of statements in a program that have been executed during testing. A good coverage tool will also indicate the places in a program that have not been covered.

In showing how JMangler can be used to implement a coverage tool, we concentrate on line coverage, the percentage of lines of code covered by tests.

A code transformer for collecting line coverage information is listed and explained in detail in Appendix 15.A. CC4J, a full-fledged, commercial code coverage tool deployed in large scale industrial software projects is described in [31]. Its core is a similar transformer for the BCEL weaver of JMangler (see Figure 15-6). Unlike the vanilla version presented in the appendix, it supports collecting coverage information from multiple test runs and their user-friendly presentation that immediately directs programmers to the untested spots of the application. Also, it is considerably more efficient.

Figure 15-6. Architecture of CC4J, a commercial code coverage tool implemented with JMangler.

Summarizing, JMangler offers considerable expressive power but is clearly a tool for "experts." It is typically used as a back-end for the implementation of easier to use, high-level aspect tools and systems. This is reflected in all the case studies presented in this section.