Aspect Language Implementation Architecture (ALIA) This page is maintained by Christoph Bockisch. Overview Introduction Downloads People Publications

supported by

Introduction

[Top] [Introduction] [Downloads] [People] [Publications]

Current compilers for aspect-oriented programming (AOP) languages map the aspect-oriented concepts of source programs to object-oriented bytecode. This hinders execution environments with dedicated support for such concepts in applying their optimizations as they have to recover the original aspect definition from bytecode. To avoid this problem, propose the Aspect Language Implementation Architecture (ALIA). At the core of this architecture we define the Execution Model for describing the pointcut-advice parts of aspects. Compilers that adhere to the proposed architecture generate code as usual for the conventional modules in the program, like classes and methods. For the pointcut-advice in the program, the compilers generate a description in terms of the Execution Model. Execution Environments in the proposed architecture understand the aspect definitions in the Execution Model and execute the conventional modules and the aspects accordingly. To facilitate optimizations in the execution environment, the Execution Model is based on the concepts of early pointcut evaluation and code generation which are prevalently used by state-of-the art AOP language implementations. Figure 1 illustrates the architecture of our approach.

Figure 1: The proposed model-centric architecture for pointcut-advice language implementations.

The Aspect Language Implementation Architecture (ALIA) decouples the development of new concepts as language extensions and the optimization of concepts in the execution environment. As result, a program that was compiled as imposed by our architecture can be executed on each virtual machine that also conforms to the architecture. This means that you can choose the best-fitting virtual machine (VM) to execute your program. Choosing between different virtual machines may sometimes be reasonable because different VMs may provide non-standard extensions or may perform especially well in certain scenarios.

Similarly, different languages can benefit from optimizations implemented in a dedicated virtual machine due to the separate intermediate representation of aspects in terms of the Execution Model. Currently, there are several aspect-oriented programming languages which generate Java bytecode. Generally, they each have at least some common building blocks. Since the model proposed in our approach is flexibly extensible, different AOP language compilers can on the one hand share common model entities and, on the other hand, extend the model with their specialities. When there is a virtual machine that optimizes such a common concept, all languages benefit from the optimization.

This project is devided into several of sub projects:

1. Generic Implementation of ALIA			We are developing a generic implementation of the proposed architecture (called the Reference Architecture) as a framework. This can be extended by execution environments that want to support the proposed approach. The Reference Architecture includes classes and interfaces that define the Execution Model for defining behavioral crosscutting, i.e., pointcut-and-advice.
2. Patterns			An important feature of aspect-oriented programming languages is the ability to quantify over points in the execution in terms of syntactic and lexical properties of the instructions that are exectued at these points. By this, we mean, e.g., the selection of method calls where the called method's name matches some pattern. This is especially important in the context of aspect weavers which perform early evaluation of pointcuts and code generation, as in the Aspect Language Implementation Architecture. In this sub-project, we provide matchers for different parts of method and field signatures.
3. Benchmarking			We are developing a benchmark suite to benchmark execution environments that understand our Execution Model.
4. Language Front-Ends for ALIA			Front-ends can be compilers or other tools that generate an Execution model description of the aspects in a program to be executed by an execution environment for the Reference Architecture.
	4.1. AspectJ Compiler		For the features of AspectJ concerned with behavioral crosscutting we provide mappings to the Execution Model. We provide an AspectJ compiler based on JastAdd that uses this mapping. The special AspectJ compiler is also integrated in a modified version of the AspectJ Development Tools (AJDT) 1.4.1. We call this the AJDT-EM where EM stands for Execution Model.
	4.2. AspectJ Importer		Another approach to support AspectJ is using the "Load-Time Weaving" of AspectJ. The standard compiler for AspectJ can be told to generate bytecode as usual, but omit the weaving of aspects. Instead, it generates a descriptor file specifying which aspects exist in the program. For aspects the compiler generates classes that contain the code of the advide bodies as methods. For the load-time weaving the compiler adds annotations to these methods that define the pointcuts to which the advice are associated. We are developing an importer that reads the descriptor file and the annotations and generated Execution Model entities from them to be executed by an execution environment for the Aspect Language Implementation.
	4.3. CaesarJ		Currently, we don't have an implementation of a CaesarJ compiler adhering to our architecture. But we plan to build one extending our special AspectJ compiler.
5. Execution Environments			We research the possibilities of of virtual machines to more naturally support the concepts that can be modeled in our Execution Model.
	5.1. Default Implementation on an Execution Environment		We have implemented a default weaver as a concretization of the Reference Architecture which does not perform serious optimizations. It is realized in terms of a Java 5 Agent using the bytecode instrumentation package for dynamic deployment.
	5.2. Steamloom Version 1		In the first version of Steamloom we have reasearched optimizations for certain concepts of AOP languages like the cflow pointcut designator and pertarget aspects.
	5.3. Steamloom VJP		We are developing a new version of the Steamloom virtual machine which is based on the technique of Virtual Join Points (VJP). This will fully support the Reference Architecture and integrate the optimizations of the first version of Steamloom.

The sub projects in more detail

4. Language Front-Ends for ALIA

As a proof-of-concept we are implementing compilers for existing AOP languages that generate code according to our architecture. We use the JastAdd compiler framework to implement our compilers.

4.1 AspectJ compiler

We have implemented a compiler for AspectJ 1.2 source code. Its main feature is to transform the pointcut and advice definitions into calls to the API defined by the Execution Model and to produce bytecode output, which may be directly executed by an execution environment that understands the Execution Model. We re-use work from the JastAdd project, which is a Java-based compiler compiler frameword using aspect-oriented mechanisms itself. Its major benefit is the modularization into different aspects offering the ability to extend it arbitrarily. All functionality is implemented combining imperative and declarative aspects. Our AspectJ compiler re-uses as much from the JastAdd Java-compiler as possible. A more in depth discussion of this AspectJ compiler can be found here.

We have integrated the ALIA AspectJ compiler into the AspectJ Development Tools (AJDT) which is the Eclipse based integrated development environment for AspectJ. For the integration, we provide a modified version of the AJDT 1.4.1. We call this the AJDT-EM (AJDT-Execution Model). Information on how to install and use the AJDT-EM can be found here. The compiler is based on an early version of the Reference Architecture and not included in the ALIA download bundle. The download of the AJDT-EM, however, contains the compiler as well as the supported version of the Reference Architecture.

4.2 AspectJ Importer

4.3 CaesarJ

Currently, we don't have an implementation of a CaesarJ compiler adhering to our architecture. But we plan to build one extending our special AspectJ compiler.

Downloads

[Top] [Introduction] [Downloads] [People] [Publications]

We provide the projects that constitute ALIA and the reference instantiations of the architecture for download as a collection of Eclipse projects. The projects were developed using Eclipse 3.3 (Europa), the AJDT 1.5 (also from the Europa simultaneous release) and the JavaCC plugin 1.5.9 (http://eclipse-javacc.sourceforge.net/). The AJDT is used for the example projects and by some of the projects that require the AspectJ runtime library. JavaCC is used by the AspectJ importer to parse AspectJ pointcuts.

Where projects have dependencies (see build path, required projects in the Eclipse properties) always use projects from the same archive. This archive has the version 0.1. The projects Patterns and BytecodeVerifier can be used stand-alone. The other projects have dependencies with each other.

After you import the projects in you workspace, you have to create a new JRE. Please note that your workspace will contain errors until you added the new JRE. Call it "Steamloom JDK 1.5" and enter the settings as for your favorit Java 5.0 or Java 6.0 JRE, but add the following Defailt VM Arguments:

-javaagent:<your workspace directory>\DefaultExecutionEnvironment\agent\steamloom.jar
-noverify
-agentpath:<your workspace directory>\DefaultExecutionEnvironment\native\SteamloomAPINative.dll
-Djava.library.path=<your workspace directory>\DefaultExecutionEnvironment\native

The -noverify flag means that the JVM does not perform bytecode verification. Normally, you would not turn this of, but in the case of the Default Execution Environment, code is intentionally generated where we can guarantee that it is correct and will not lead to errors during execution. But the verification can not recognize this. Each loaded class passes our proprietary Bytecode Verifier to guarantee safety to some degree and to support developers that add new code generations to the Default Execution Environment.

Maybe, it is required that you run the the and build script in the DefaultExecutionEnvironment project after you imported the project. The project defines a builder to automatically run it, but it does not work in all cases. It may also be necessary from you to compile the native library in the native folder. For Linux the ant build script already contains a target to generate the shared library correctly.

• ALIA related projects version 0.2.1 - Release Notes: Replaces the version 2.0 which had a bug. The ALIA Application project replaces the AspectJTestAspects project as an example for using the Reference Architecture and AspectJ importer (for a description, see above). The Reference Architecture respecitvely Default Execution Environment and the AspectJ annotations importer now support the dynamic properties args, this, target, cflow and cflowbelor. However, there are a few limitations: (1) no context can be bound for the advice method within the"cflow. (2) The implementation has a bug for pointcuts of the form pc1 && cflow(pc2) where pc1 and pc2 have shared join point shadows. The same is true for cflowbelow. (3) In AspectJ pointcuts of the form execution(pc) && this(o) will not bind the object which is currently executing (as specified by AspectJ) but the caller object. Finally, it is not allowed to specify DynamicProperties that require the ResultContext. (3) The AspectJ importer only supports before advice. after, after returning, after throwing, around, and named pointcuts are not supported.
• ALIA related projects version 0.1

People

[Top] [Introduction] [Downloads] [People] [Publications]

Actively Involved

Formerly Involved

Publications

[Top] [Introduction] [Downloads] [People] [Publications]