FAQ

1. What is XAspects?
XAspects delivers the xajc command together with a library of ready-to-use plug-ins. The xajc command is a wrapper around the AspectJ compiler that introduces macro-like features to allow domain-specific aspect languages to be implemented as if they were an extension to the AspectJ language itself. Each macro is implemented using a plug-in interface and can be used by adding the plug-in in your class-path when invoking the xajc command. The XAspects library implements a set of plug-ins that are useful for several different domains but represents only the beginning of the possible plug-ins that can be written.

2. What kind of domain-specific aspects?
XAspects currently supports the domains of adaptive programming (as supported by DemeterJ's concepts of traversals and class-dictionaries), thread coordination (as supported by the COOL system), and remote invocation (as supported by the RIDL system). Several more domains are being considered for the next batch of plug-ins (for example, personalities and the Gang of Four design patterns).

3. How do I use plug-ins from within XAspects?
In your AspectJ source files (which can be regular Java source files too) you “pass” a type name to the aspect keyword:

1.
2.
3.
4.
5.
6.
7.

aspect(ClassDictionary) ExpressionLanguage {
    // A grammar in Backus-Naur form:
    Expr: Simple | Addition | Subtraction.
    Simple = Integer.
    Addition = Simple "+" Expr.
    Subtraction = Simple "-" Expr.
}

Here, “ClassDictionary” (on line 1) is the type-name that specifies how to interpret the code on lines 2 to 7. The code is neither Java nor AspectJ syntax, but rather the syntax of the ClassDictionary plug-in. A plug-in is a Java object that implements the abstract methods of the AspectPlugin class. Any such class that appears in your class path can be used by XAspects. Each plug-in can have its own syntax, provided it uses only valid Java tokens and does not have any dangling left or right curly brackets.

4. How to plug-ins interact with each other?
The compilation of plug-ins is a two phase process. After each plug-in is given the bodies of code specified by the user, each plug-in will specify the new APIs introduced by the plug-in. The new APIs could include new classes or new fields or methods to be added to existing classes. From this information, the class graph of the whole program can be constructed and the second phase begins. In the second phase each plug-in specifies the implementation of the APIs it introduced, plus any additional support classes or aspects. Because each plug-in has the opportunity to view the whole program in bytecode form the additions made by other plug-ins are visible to every one. In this way, classes defined by the ClassDictionary aspect can be used by the Traversal aspect. It may sound odd that a “macro” is getting (read-only) access to all of the bytecodes of the program, but because aspects are specifically focused on concerns that cross-cut the program this is quite natural. Aspects can only change other code through AspectJ's join-point model.

5. What are the join-points of XAspects?
Because each aspect body is replaced with AspectJ code generated by the plug-ins the join-points of the plug-ins themselves are limited to AspectJ's join-point model. When complemented with the bytecodes very powerful languages can be implemented that could not easily be expressed in neither Java nor AspectJ. For example, the Visitor pattern requires detailed hand-coding in either Java or AspectJ, but can be performed automatically through the Traversal plug-in.

6. I confess I don't know too much about DemeterJ or Traversals, how else is XAspects useful?
You can think of XAspects as a way of simplifying library usage and abstracting away patterns that may be too tricky to write in AspectJ. Another example would be to support a high-level authorization language:

aspect(Authorization) StudentEnrollment {
    declare policy: allow read(Enrollment e) if user in e.students.advisor;
}

Here, a global property specifies that calls to the read method should only be allowed if a specific condition holds. This property will apply to the whole program without having to change any of the existing code. Such problems are easily solved in AspectJ but using such higher-level languages can make it easier for a beginner programmer who wants to be effective in AspectJ immediately.

7. How is XAspects different from hygienic macros?

• domain-specific aspects generate Java classes and AspectJ aspects;

• domain-specific aspects can only modify existing code via AspectJ's advice or AspectJ's intertype declarations;

• domain-specific aspects have access to the entire program to decide what functionality to generate; and

• domain-specific aspects can compute anything a Java/AspectJ program can compute (this computation happens at compile time, not run-time).

8. Where does the name XAspects come from?
XAspects is a system for defining domain-specific languages that can plug into AspectJ or Java programs. The features allowed to the plug-ins are powerful enough that many domain-specific aspect languages can be plugged in. So, XAspects is a system of extending the AspectJ language, or you can think of the language now as being extensible. So, in that case, the X comes from the same root as XML.

Another interpretation of the name is that this project revitalizes aspect-oriented solutions that were abandoned from the AspectJ language for being too specific. For example, the COOL language was removed from AspectJ, making it an ex-aspect. Now with the XAspects project, there is a framework for bringing all of the ex-aspects back!