Section 15.1. INTRODUCTION

15.1. INTRODUCTION

AOSD improves separation of concerns by enabling the modular expression of crosscutting concerns. Modular implementation of a concern as one aspect^[1] requires techniques to "weave" this implementation back into the code of all classes that require the concern. For instance, logging behavior expressed in one aspect must be "woven" into all the classes of a system whose activities should be recorded.

^[1] We use aspect as a generic term for a module that encapsulates the implementation of one concern, abstracting from the particular language concepts of AspectJ [30], ComposeJ [6, 45], DJ [38], Hyper/J [39, 40], and other AOSD systems.

15.1.1. Challenges for Aspect Weaving

A general solution for aspect weaving must deal with different times and development contexts.

Weaving can be performed before a program starts (compile-time or static weaving), at load-time (load-time weaving), or after a class is loaded (dynamic weaving). Static weaving has the advantage of adding no unnecessary run-time penalty to a program's execution. However, in a dynamic class-loading context, static weaving has the weakness that it cannot enforce aspect application to dynamically loaded classes. With static weaving, we have to trust the programmer to identify the classes that belong to a program. In Java,^[2] the only way to be sure of which classes are actually used by a program is by checking during dynamic class loading.

^[2] Since JMangler targets Java class files, all our discussions are in the context of the Java language (and conservative extensions thereof).

Weaving might be applied in fully controlled contexts or in partly controlled contexts, depending on how the woven entities are created and stored and in which format they are available. A program can be available as source code or in compiled form. Source code and compiled code can be entirely available beforehand, or parts of it can be generated at runtime. Code can be stored locally or on a remote host. Full control means that every part of the program is available as source code, and the code is stored locally and is entirely available beforehand. Otherwise, we have only partial control. These relationships are illustrated in Table 15-1.

Table 15-1. Contexts of Weaving

	Controlled	Uncontrolled
Format	source code	compiled code
Creation	beforehand	during runtime
Storage	local	remote

Another challenge for weaving is managing variants. Not every incarnation of a system requires every aspect. In general, the number of possible variants grows exponentially with the number of possible adaptations. Depending on its context of use, an application might need to integrate a logging aspect, might apply an observer aspect for monitoring different subsets of the program state [24], might need to apply various security or synchronization exception handling policies [7], and so forth. In their discussion of "jumping aspects," for instance, Brichau, Meuter, and de Volder [7] show that different exception handling policies are required if an application is deployed standalone or as a component of another application.

It could be prohibitive to generate all these variants statically and in advance. For these reasons, we need means for instrumenting the code base "on-the-fly," depending on the actual needs of an application in a concrete deployment scenario.

15.1.2. Promises of Load-Time Analysis and Transformation (LAT)

Processing binaries at load time makes it possible to address many of the challenges mentioned above. Load-time analysis and transformation of class files (subsequently called LAT) can be used to implement load-time weaving or to insert code that performs run-time weaving. With a tool that can store transformed classes, LAT can also be used for static weaving of binary code.

LAT is inherently applicable to black-box components delivered by third parties in binary format and is oblivious of the local or remote origin of binaries and of their static or dynamic creation.

LAT processes only classes relevant in a given application context. It can further prevent static version proliferation by taking advantage of dynamic information for selection of relevant transformations and for their specialization to current run-time conditions.

15.1.3. Aspect-Oriented LAT with JMangler

The advantages of load-time transformation have motivated the development of various LAT tools and frameworks for Java class files. JMangler differs from other approaches in four main regards:

• It provides "generic interception" of application class files, allowing transformation of any application classes independent of a custom JVM and of whether the transformed application uses its own class loaders [33]. Therefore, it enables load-time adaptation in environments like application servers, which make heavy use of custom class loaders [31].

• As of version 3, JMangler has an open architecture that facilitates the integration of "weavers," which perform the real transformation of Java class files. Weavers inherit JMangler's generic interception ability, so they can be implemented on top of all existing class file transformation frameworks [4, 8, 9, 11, 12, 34, 35], including those that were not designed for load-time use.

• JMangler extends the Java class-loading model by providing nested class loading: while loading and transforming a class, it is possible to load, analyze, and transform further classes. This enables non-local load-time transformations, which depend on the contents of multiple class files.

• JMangler includes a weaver that provides a partial solution to the problem of aspect interference. For a certain class of transformations, it can guarantee that their joint use will not lead to undesired effects (interferences) even if the transformations have been developed independently [33].

JMangler and its relation to other LAT tools are described in [10, 33]. Details of its use and various features that go beyond the scope of this paper are described in the tutorial that is available online and as part of the JMangler distribution [26]. A commercial development tool built with JMangler is presented in [31].

In Section 15.2, we introduce the notion of generic interception and explain how JMangler achieves generic interception. Then we present its open architecture, which enables other frameworks to be used as plug-ins for JMangler (Section 15.3), and we describe the treatment of non-local dependencies (Section 15.4).

In Section 15.5, we introduce the concepts behind the weaver included in JMangler as far as necessary to understand its use in different AOSD scenarios. In Section 15.6, we discuss a few typical application scenarios: development of higher-level aspect tools, load-time weaving, run-time weaving, and applications beyond the expressive power of existing high-level AOSD languages. Section 15.7 examines related work. In Section 15.8, we summarize ongoing and future work before concluding. Appendix 15.A illustrates the implementation of a code transformer.