Overview

XAspects is the result of a class project for Adaptive Object-Oriented Software Development. The goal of the project is to explore ways of integrating domain-specific aspect-oriented solutions into general purpose aspect-oriented programming. The key idea behind this integration is to translate domain-specific aspects at compile time into general AspectJ source code. In this way, AspectJ serves as a base language from which other aspects can be defined.

As a case study, the DemeterJ project will be redone using this plug-in style (leveraging the work of the DAJ project). Below is an example that uses a ClassDictionary aspect, a Traversal aspect, a TraversalAdvice aspect, and an AspectJ aspect: (This example is courtesy of Prof. Karl Lieberherr.)

import edu.neu.ccs.xaspects.*;

aspect(ClassDictionary) FileSys {
    // EBNF
    FileSystem = <root> CompoundFile EOF.
    File : SimpleFile | CompoundFile common <name> Ident.
    SimpleFile = "simple".
    CompoundFile = "compound" <contents> FileList [<parent> CompoundFile].
    FileList ~ "(" { File } ")".
}

aspect(Traversal) FileSystemTraversals {
    declare strategy: eachFile: "intersect(from CompoundFile to File, down)";
    declare traversal: void listAll(): eachFile (FileLister);
    declare strategy: down: "from * bypassing -> *,parent,* to *";
    declare strategy: up: "from * bypassing -> *,contents,* to *";
}

aspect(AspectJ) FileSystemMethods {
    File CompoundFile.getFile(Ident name) {
        for (Iterator it = contents.iterator(); it.hasNext(); ) {
            File file = (File)it.next();
            if (file.name.equals(name))
                return file;
        }
        return null;
    }
}

aspect(TraversalAdvice) FileLister {
    // Happens to be a Java class
    Stack path = new Stack();
    void before(File file) {
        path.push(file.name);
    }
    void after(File file) {
        System.out.print("      .");
        Iterator it = path.iterator(); it.next(); 
        while (it.hasNext())
            System.out.print("/" + it.next());
        System.out.println();
        path.pop();
    }
}

class Main {
    public static void main (String[] args) {
        FileSystem fs = FileSystem.parse(new File(args[0]));
        System.out.println(" Status of File System ");
        fs.root.listAll();
    }
}

Here, the [ClassDictionary] aspect has the features of a parser generator together with the ability to name the fields and relationships of several classes. The [ClassDictionary] plug-in is invoked at compile-time to generate both the classes and their parser. Seven different classes are defined, yet the aspect body only took five lines to describe.

The [Traversal] plug-in is invoked in a later phase of compilation and has access to the class-graph of the program which is currently being compiled. Using special syntax, traversals over the class-graph can be described clearly and succinctly.

The [AspectJ] plug-in is a standard AspectJ-style aspect (it is merely a wrapper for completeness).

Finally, the [TraversalAdvice] plug-in defines a class that implements the visitor pattern. (A [Traversal] describes where to go, while a [TraveralAdvice] describes what to do.)

Without special notation for traversals (which you can think of as paths through a UML-style class diagram) the relationships of the classes would have to be repeated in the code (through several methods defined in the File class down to the SimpleFile and CompoundFile classes). This repetition causes difficulties because any changes to the class-graph require changes to the traversal code. (Moreover, with repetition the code to manage is longer and the temptation to take coding short cuts is stronger.) The traversal notation adds more power to the programmer in a very limited, well defined manner.

This plug-in architecture can be useful for more than just parser, class, and traversal generation. Plug-ins are currently being written to support the COOL and RIDL systems. Each plug-in alone is too specific to be included into the AspectJ programming language, but each is useful enough that separate tools have been created to support all of their styles of programming. By implementing domain-specific aspects, AspectJ can support stronger aspect libraries and can use some of the most compelling arguments for the aspect-oriented programming paradigm. At the start of AOP, domain-specific solutions came first and only later did general-purpose (but, by design, inherently less powerful) solutions get created. This project aims to get the best of both worlds.

Ankit Shah (ankit[at]ccs.neu.edu)
Macneil Shonle (mshonle[at]ccs.neu.edu)