Aspect weaver

Many programming languages are already widely accepted and understood. However, the desire to create radically different programming languages to support the aspect-oriented programming paradigm is not significant due to business-related concerns; there are risks associated with adopting new technologies.[1] Use of an entirely new language relies on a business's ability to acquire new developers. Additionally, the existing code base of a business would need to be discarded. Finally, a business would need to acquire a new toolchain (suite of tools) for development, which is often both an expense in both money and time.[2] Primary concerns about roadmaps for the adoption of new technologies tend to be the need to train new developers and adapt existing processes to the new technology.[3]

To address these business concerns, an aspect weaver enables the use of widely adopted languages like Java with aspect-oriented programming through minor adaptations such as AspectJ which work with existing tools.[4] Instead of developing an entirely new language, the aspect weaver interprets the extensions defined by AspectJ and builds "woven" Java code which can then be used by any existing Java compiler. This ensures that any existing object oriented code will still be valid aspect-oriented code and that development will feel like a natural extension of the object-oriented language.[5] The AspectC++ programming language extends C++ through the use of an aspect weaver, offering the additional efficiency over AspectJ that is necessary for embedded systems while still retaining the benefits of aspect-oriented programming.[6]

Aspect weavers operate by taking instructions specified by aspects, known as advice, and distributing it throughout the various classes in the program automatically. The result of the weaving process is a set of classes with the same names as the original classes but with additional code injected into the classes' functions automatically. The advice specifies the exact location and functionality of the injected code.[7]

Through this weaving process, aspect weavers allow for code which would have otherwise been duplicated across classes. By eliminating this duplication, aspect weavers promote modularity of cross-cutting concerns.[8] Aspects define the implementation code which would have otherwise been duplicated and then use pointcuts and join points to define the advice. During weaving, the aspect weaver uses the pointcuts and join points, known as a pointcut designator, to identify the positions in candidate classes at which the implementation should be injected.[9] The implementation is then injected into the classes at the points identified, thus permitting the code to be executed at the appropriate times without relying on manual duplication by the programmer.[10]

aspect Logger {
    pointcut method() : execution(* *(..));
    before() : method() {
        System.out.println("Entering " + 
            thisJoinPoint.getSignature().toString());
    }
    after() : method() { 
        System.out.println("Leaving " + 
            thisJoinPoint.getSignature().toString());
    }
}
public class Foo {
    public void bar() {
        System.out.println("Executing Foo.bar()");
    }
    public void baz() {
        System.out.println("Executing Foo.baz()");
    }
}

public class Foo {
    public void bar() {
        System.out.println("Entering Foo.bar()");
        System.out.println("Executing Foo.bar()");
        System.out.println("Leaving Foo.bar()");
    }
    public void baz() {
        System.out.println("Entering Foo.baz()");
        System.out.println("Executing Foo.baz()");
        System.out.println("Leaving Foo.baz()");
    }
}

Aspect weavers' performance, as well as the performance of the code that they produce, has been a subject of analysis. It is preferable that the improvement in modularity supplied by aspect weaving does not impact run-time performance. Aspect weavers are able to perform aspect-specific optimizations.[21] While traditional optimizations such as the elimination of unused special variables from aspect code can be done at compile-time, some optimizations can only be performed by the aspect weaver. For example, AspectJ contains two similar but distinct keywords, thisJoinPoint, which contains information about this particular instance of woven code, and thisJoinPointStaticPart, which contains information common to all instances of code relevant to that set of advice. The optimization of replacing thisJoinPoint with the more efficient and static keyword thisJoinPointStaticPart can only be done by the aspect weaver. By performing this replacement, the woven program avoids the creation of a join point object on every execution.[14] Studies have shown that the unnecessary creation of join point objects in AspectJ can lead to a performance overhead of 5% at run-time, while performance degradation is only approximately 1% when this object is not created.[22]

Compile-time performance is generally worse in aspect weavers than their traditional compiler counterparts due to the additional work necessary for locating methods which match the specified pointcuts. A study done showed that the AspectJ compiler ajc is about 34% slower than the Sun Microsystems Java 1.3 compiler and about 62% slower than the Java 1.4 compiler.[23]

• Aspect-oriented programming
• Preprocessor
• Compiler

• Suzuki, Junichi; Yamamoto, Yoshikazu (June 1999). Moreira, A. M.; Demeyer, Moreira (eds.). "Extending UML with Aspects: Aspect Support in the Design Phase" (PDF). Proceedings of the Workshop on Object-Oriented Technology. 1743: 299–300. Archived from the original (PDF) on 22 July 2011. Retrieved 4 January 2010.