Aspect weaver

Last updated

Available in AspectC++, AspectJ
Type Aspect-oriented programming

An aspect weaver is a metaprogramming utility for aspect-oriented languages designed to take instructions specified by aspects (isolated representations of significant concepts in a program) and generate the final implementation code. The weaver integrates aspects into the locations specified by the software as a pre-compilation step. By merging aspects and classes (representations of the structure of entities in the program), the weaver generates a woven class.

Contents

Aspect weavers take instructions known as advice specified through the use of pointcuts and join points, special segments of code that indicate what methods should be handled by aspect code. The implementation of the aspect then specifies whether the related code should be added before, after, or throughout the related methods. By doing this, aspect weavers improve modularity, keeping code in one place that would otherwise have been interspersed throughout various, unrelated classes.

Motivation

Many programming languages are already widely accepted and understood. However, there is no significant desire to create radically different programming languages to support the aspect-oriented programming paradigm due to business-related 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 expensive in both money and time. [2] Primary concerns about roadmaps for the adoption of new technologies include 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 needed for embedded systems while still retaining the benefits of aspect-oriented programming. [6]

Implementation

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

Through this weaving process, aspect weavers allow for code which otherwise would have been duplicated across classes. By eliminating this duplication, aspect weavers promote modularity of cross-cutting concerns. [8] Aspects define the implementation code which otherwise would have 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]

aspectLogger{pointcutmethod():execution(**(..));before():method(){System.out.println("Entering "+thisJoinPoint.getSignature().toString());}after():method(){System.out.println("Leaving "+thisJoinPoint.getSignature().toString());}}publicclassFoo{publicvoidbar(){System.out.println("Executing Foo.bar()");}publicvoidbaz(){System.out.println("Executing Foo.baz()");}}
A sample aspect and class defined in the AspectJ programming language
publicclassFoo{publicvoidbar(){System.out.println("Entering Foo.bar()");System.out.println("Executing Foo.bar()");System.out.println("Leaving Foo.bar()");}publicvoidbaz(){System.out.println("Entering Foo.baz()");System.out.println("Executing Foo.baz()");System.out.println("Leaving Foo.baz()");}}
The woven class that results from executing an aspect weaver on the above sample

Weaving in AspectJ

In the programming language AspectJ, pointcuts, join points, and the modularized code are defined in an aspect block similar to that of Java classes. Classes are defined using Java syntax. The weaving process consists of executing the aspect advice to produce only a set of generated classes that have the aspect implementation code woven into it. [11]

The example at right shows a potential implementation of an aspect which logs the entry and exit of all methods. Without an aspect weaver, this feature would require duplication of code in the class for every method. Instead, the entry and exit code is defined solely within the aspect. [12]

The aspect weaver analyzes the advice specified by the pointcut in the aspect and uses that advice to distribute the implementation code into the defined class. The code differs slightly in each method due to slight variances in requirements for the method (as the method identifier has changed). The aspect weaver determines the appropriate code to generate in each situation as defined by the implementation advice and then injects it into methods matching the specified pointcut. [13]

Weaving to bytecode

Instead of generating a set of woven source code, some AspectJ weavers instead weave the aspects and classes together directly into bytecode, acting both as the aspect weaver and compiler. [14] [15] It is expected that the performance of aspect weavers which also perform the compilation process will require more computation time due to the weaving process involved. However, the bytecode weaving process produces more efficient runtime code than would usually be achieved through compiled woven source.

Run-time weaving

Developments in AspectJ have revealed the potential to incorporate just-in-time compilation into the execution of aspect-oriented code to address performance demands. [16] At run-time, an aspect weaver could translate aspects in a more efficient manner than traditional, static weaving approaches. Using AspectJ on a Java Virtual Machine, dynamic weaving of aspects at run-time has been shown to improve code performance by 26%. [17] While some implementations of just-in-time virtual machines implement this capability through a new virtual machine, some implementations can be designed to use features that already exist in current virtual machines. [18] [19] The requirement of a new virtual machine is contrary to one of the original design goals of AspectJ. [5]

To accomplish just-in-time weaving, a change to the virtual machine that executes the compiled bytecode is needed. A proposed solution for AspectJ uses a layered approach which builds upon the existing Java Virtual Machine to add support for join point management and callbacks to a Dynamic Aspect-Oriented Programming Engine. [19] An alternative implementation uses a weaving engine that uses breakpoints to halt execution at the pointcut, select an appropriate method, embed it into the application, and continue. [20] The use of breakpoints in this manner has been shown to reduce performance due to a very large number of context switches. [17]

Performance

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 needed for locating methods which match the specified pointcuts. One study 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]

See also

Related Research Articles

Computer programming or coding is the composition of sequences of instructions, called programs, that computers can follow to perform tasks. It involves designing and implementing algorithms, step-by-step specifications of procedures, by writing code in one or more programming languages. Programmers typically use high-level programming languages that are more easily intelligible to humans than machine code, which is directly executed by the central processing unit. Proficient programming usually requires expertise in several different subjects, including knowledge of the application domain, details of programming languages and generic code libraries, specialized algorithms, and formal logic.

In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state and implementations of behavior.

<i>Design Patterns</i> 1994 software engineering book

Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk.

In software engineering and computer science, abstraction is the process of generalizing concrete details, such as attributes, away from the study of objects and systems to focus attention on details of greater importance. Abstraction is a fundamental concept in computer science and software engineering, especially within the object-oriented programming paradigm. Examples of this include:

In computing, aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. It does so by adding behavior to existing code without modifying the code, instead separately specifying which code is modified via a "pointcut" specification, such as "log all function calls when the function's name begins with 'set'". This allows behaviors that are not central to the business logic to be added to a program without cluttering the code of core functions.

<span class="mw-page-title-main">Common Lisp Object System</span>

The Common Lisp Object System (CLOS) is the facility for object-oriented programming in ANSI Common Lisp. CLOS is a powerful dynamic object system which differs radically from the OOP facilities found in more static languages such as C++ or Java. CLOS was inspired by earlier Lisp object systems such as MIT Flavors and CommonLoops, although it is more general than either. Originally proposed as an add-on, CLOS was adopted as part of the ANSI standard for Common Lisp and has been adapted into other Lisp dialects such as EuLisp or Emacs Lisp.

In computing, just-in-time (JIT) compilation is compilation during execution of a program rather than before execution. This may consist of source code translation but is more commonly bytecode translation to machine code, which is then executed directly. A system implementing a JIT compiler typically continuously analyses the code being executed and identifies parts of the code where the speedup gained from compilation or recompilation would outweigh the overhead of compiling that code.

AspectJ is an aspect-oriented programming (AOP) extension for the Java programming language, created at PARC. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become a widely used de facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-like syntax, and included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

In programming language theory and type theory, polymorphism is the use of a single symbol to represent multiple different types.

In computer science, a metaobject is an object that manipulates, creates, describes, or implements objects. The object that the metaobject pertains to is called the base object. Some information that a metaobject might define includes the base object's type, interface, class, methods, attributes, parse tree, etc. Metaobjects are examples of the computer science concept of reflection, where a system has access to its own internal structure. Reflection enables a system to essentially rewrite itself on the fly, to alter its own implementation as it executes.

In object-oriented programming, delegation refers to evaluating a member of one object in the context of another original object. Delegation can be done explicitly, by passing the responsibilities of the sending object to the receiving object, which can be done in any object-oriented language; or implicitly, by the member lookup rules of the language, which requires language support for the feature. Implicit delegation is the fundamental method for behavior reuse in prototype-based programming, corresponding to inheritance in class-based programming. The best-known languages that support delegation at the language level are Self, which incorporates the notion of delegation through its notion of mutable parent slots that are used upon method lookup on self calls, and JavaScript; see JavaScript delegation.

<span class="mw-page-title-main">Gregor Kiczales</span> American computer scientist

Gregor Kiczales is an American computer scientist. He is currently a professor of computer science at the University of British Columbia in Vancouver, British Columbia, Canada. He is best known for developing the concept of aspect-oriented programming, and the AspectJ extension to the Java programming language, both of which he designed while working at Xerox PARC. He is also one of the co-authors of the specification for the Common Lisp Object System, and is the author of the book The Art of the Metaobject Protocol, along with Jim Des Rivières and Daniel G. Bobrow.

In object-oriented programming, inheritance is the mechanism of basing an object or class upon another object or class, retaining similar implementation. Also defined as deriving new classes from existing ones such as super class or base class and then forming them into a hierarchy of classes. In most class-based object-oriented languages like C++, an object created through inheritance, a "child object", acquires all the properties and behaviors of the "parent object", with the exception of: constructors, destructors, overloaded operators and friend functions of the base class. Inheritance allows programmers to create classes that are built upon existing classes, to specify a new implementation while maintaining the same behaviors, to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed acyclic graph.

In computer programming, a trait is a concept used in programming languages which represents a set of methods that can be used to extend the functionality of a class.

In compiler optimization, escape analysis is a method for determining the dynamic scope of pointers – where in the program a pointer can be accessed. It is related to pointer analysis and shape analysis.

<span class="mw-page-title-main">Greenfoot</span>

Greenfoot is an integrated development environment using Java or Stride designed primarily for educational purposes at the high school and undergraduate level. It allows easy development of two-dimensional graphical applications, such as simulations and interactive games.

In computing, subject-oriented programming is an object-oriented software paradigm in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions ("subjects") of the objects. The term and concepts were first published in September 1993 in a conference paper which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996. As illustrated in that paper, an analogy is made with the contrast between the philosophical views of Plato and Kant with respect to the characteristics of "real" objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird's nor the tax-assessor's additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant's analysis, the same may be true even of characteristics we think of as intrinsic.

Agent-oriented programming (AOP) is a programming paradigm where the construction of the software is centered on the concept of software agents. In contrast to object-oriented programming which has objects at its core, AOP has externally specified agents at its core. They can be thought of as abstractions of objects. Exchanged messages are interpreted by receiving "agents", in a way specific to its class of agents.

Gradual typing is a type system in which some variables and expressions may be given types and the correctness of the typing is checked at compile time and some expressions may be left untyped and eventual type errors are reported at runtime. Gradual typing allows software developers to choose either type paradigm as appropriate, from within a single language. In many cases gradual typing is added to an existing dynamic language, creating a derived language allowing but not requiring static typing to be used. In some cases a language uses gradual typing from the start.

The composition filters model denotes a modular extension to the conventional object model. It provides a solution for a wide range of problems in the construction of large and complex applications. Most notably, one implementation of composition filters provides an abstraction layer for message-passing systems.

References

  1. Kiczales (October 2001), p.2
  2. Kiczales (October 2001), p.7
  3. Colyer (2003), p.6
  4. Kiczales (October 2001), p.5
  5. 1 2 Kiczales (June 2001), p.3
  6. Spinczyk (2002), p.1
  7. Wand (2004), p.1
  8. Wand (2004), p.7
  9. Viega (November 2000), p.2
  10. Spinczyk (October 2007), p.21
  11. Wang (July 2007), p.4
  12. Avgustinov (2007), p.2
  13. Hilsdale (2004), pp.56
  14. 1 2 Hilsdale (2004), p.2
  15. McEachen (2005), p.1
  16. Popovici (2003), p.1
  17. 1 2 Sato (September 2003), p.17
  18. Sato (September 2003), p.2
  19. 1 2 Papovici (2003), p.3
  20. Sato (September 2003), p.11
  21. Gal (2001), p.3
  22. Colyer (2003), p.2
  23. Hilsdale (2004), p.7

Bibliography

Further reading