AspectJ(tm) is a simple and practical extension to the Java(tm) programming language that adds to Java aspect-oriented programming (AOP) capabilities. AOP allows developers to reap the benefits of modularity for concerns that cut across the natural units of modularity. In object-oriented programs like Java, the natural unit of modularity is the class. In AspectJ, aspects modularize concerns that affect more than one class.

AspectJ includes a compiler (ajc), a debugger (ajdb), a documentation generator (ajdoc), a program structure browser (ajbrowser), and integration with JBuilder, Forte and GNU Emacs/XEmacs.

You compile your program using the AspectJ compiler (perhaps using the supported development environments) and then run it, supplying a small (29K) runtime library.

AspectJ can be used to improve the modularity of software systems.

Using ordinary Java, it can be difficult to modularize design concerns such as

The code for these concerns tends to be spread out across the system. Because these concerns won't stay inside of any one module boundary, we say that they crosscut the system's modularity.

AspectJ adds constructs to Java that enable the modular implementation of crosscutting concerns. This ability is particularly valuable because crosscutting concerns tend to be both complex and poorly localized, making them hard to deal with.

AspectJ has been designed as a compatible extension to Java. By compatible, we mean

The AspectJ tools run on any Java 2 Platform compatible platform. The AspectJ compiler produces classes that run on any Java 1.1 (or later) compatible platform.

The AspectJ tools are open-source software available under the Mozilla Public License 1.1. The documentation is available under a separate license that precludes for-profit or commercial redistribution. Generally, we permit some usage for internal presentations; please contact us at support@aspectj.org for permission.

AspectJ is based on over ten years of research at Xerox Palo Alto Research Center as funded by Xerox, a U.S. Government grant (NISTATP), and a DARPA contract.

It has evolved through open-source releases to a strong user community. The AspectJ team works closely with the community to ensure AspectJ continues to evolve as an effective aspect-oriented programming language and tool set.

The latest release is 1.0.3 which can be downloaded from the AspectJ download page. Further development is focused on supporting applications, improving performance of the 1.0 compiler, enhancing integration with IDEs, and building the next generations of the language.

The AspectJ compiler produces programs for any released version of the Java platform (jdk1.1 and later). When running, your program classes must be able to reach classes in the small 29K runtime library (aspectjrt.jar) from the distribution. The tools themselves require Java 2 (jdk1.2) or later to run, but the compiler can be set up to target any 1.1-compliant version of the Java platform.

Go to AspectJ's download web page and choose which components you want download. The jar files are installed by executing

            java -jar jar file name
          

Do not try to extract the jar file contents and then attempt to execute java org.aspectj.Main. (A NoClassDefFoundError exception will be thrown.) The AspectJ distribution is not designed to be installed this way. Use the java -jar form shown above.

The compressed tar files (suffix: .tgz) are extracted by decompressing them with tar or with WinZip.

To uninstall, remove the files the installer wrote in your file system. In most cases, you can delete the top-level install directory (and all contained files), after you remove any new or updated files you want to keep. On Windows, no registry settings were added or changed, so nothing needs to be undone. You may install over prior versions, but if the files are locked the installer will warn you but still complete; in this case, remove the locked files and reinstall.

Many users adopt AspectJ incrementally, first using it to understand and validate their systems (relying on it only in development) and then using it to implement crosscutting concerns in production systems. AspectJ has been designed to make each step discrete and beneficial.

In order of increasing reliance, you may use AspectJ:

This adoption sequence works well in practice and has been followed by many projects.

AspectJ products are designed to make it easy to integrate AspectJ into an existing development process. Each release includes Ant taskdefs for building programs, the AspectJ Development Environment (AJDE) for writing aspects inside popular IDE's, and command-line tools for compiling, documenting, and debugging.

AspectJ provides replacements for standard Java tools:

The AspectJ Development Environment (AJDE) enables programmers to view and navigate the crosscutting structures in their programs, integrated with existing support in popular Java IDE's for viewing and navigating object-oriented structures. For many programmers this provides a deeper understanding of how aspects work to modularize their concerns and permits them to incrementally extend their development practices without having to abandon their existing tools.

AJDE integrates with the following tools:

The common functionality of AJDE is also available in the stand-alone source code browser ajbrowser, included in the tools distribution.

AspectJ also supports building with Ant 1.3 by providing taskdef interfaces to the ajc and ajdoc tools.

No. Although AspectJ can be used in a way that allows AspectJ code to be removed for the final build, aspect-oriented code is not always optional or non-functional. Consider what AOP really does: it makes the modules in a program correspond to modules in the design. In any given design, some modules are optional, and some are not.

The examples directory included in the AspectJ distribution contains some examples of the use aspects that are not optional. Without aspects,

Production aspects are delivered with the finished product, while development aspects are used during the development process. Often production aspects are also used during development.

Aspects for logging, tracing, debugging, profiling or performance monitoring, or testing.

Aspects for performance monitoring and diagnostic systems, display updating or notifications generally, security, context passing, and error handling.

"Scattering" is when similar code is distributed throughout many program modules. This differs from a component being used by many other components since it involves the risk of misuse at each point and of inconsistencies across all points. Changes to the implementation may require finding and editing all affected code.

"Tangling" is when two or more concerns are implemented in the same body of code or component, making it more difficult to understand. Changes to one implementation may cause unintended changes to other tangled concerns.

"Crosscutting" is how to characterize a concern than spans multiple units of OO modularity - classes and objects. Crosscutting concerns resist modularization using normal OO constructs, but aspect-oriented programs can modularize crosscutting concerns.

Join points are well-defined points in the execution of a program. Not every execution point is a join point: only those points that can be used in a disciplined and principled manner are. So, in AspectJ, the execution of a method call is a join point, but "the execution of the expression at line 37 in file Foo.java" is not.

The rationale for restricting join points is similar to the rationale for restricting access to memory (pointers) or restricting control flow expressions (goto) in Java: programs are easier to understand, maintain and extend without the full power of the feature.

AspectJ join points include reading or writing a field; calling or executing an exception handler, method or constructor.

A pointcut picks out join points . These join points are described by the pointcut declaration. Pointcuts can be defined in classes or in aspects, and can be named or be anonymous.

Advice is code that executes at each join point picked out by a pointcut. There are three kinds of advice: before advice, around advice and after advice. As their names suggest, before advice runs before the join point executes; around advice executes before and after the join point; and after advice executes after the join point. The power of advice comes from the advice being able to access values in the execution context of a pointcut.

AspectJ enables you to declare members and supertypes of another class in an aspect, subject to Java's type-safety and access rules. These are visible to other classes only if you declare them as accessible. You can also declare compile-time errors and warnings based on pointcuts.

Aspects are a new class-like language element that has been added to Java by AspectJ. Aspects are how developers encapsulate concerns that cut across classes, the natural unit of modularity in Java.

Aspects are similar to classes because...

Aspects are different than classes because...

AOP's fundamental assumption is that in any sufficiently complex system, there will inherently be some crosscutting concerns.

So, while there are some cases where you could re-factor a system to make a concern no longer be crosscutting, the AOP idea is that there are many cases where that is not possible, or where doing so would damage the code in other ways.

Yes.

The short summary is that it is right to define AOP in terms of crosscutting, because well-written AOP programs have clear crosscutting structure. It would be a mistake to define AOP in terms of "cleaning up tangling and scattering", because that isn't particular to AOP, and past programming language innovations also do that, as will future developments.

Slides for a long talk on this topic are at http://www.cs.ubc.ca/~gregor/vinst-2-17-01.zip .

No. Some implementations of AOP are domain-specific, but AspectJ was specifically designed to be general-purpose.

There are many mechanisms people use now to implement some crosscutting concerns. But they don't have a way to express the actual structure of the program so you (and your tools) can reason about it. Using a language enables you to express the crosscutting in first-class constructs. You can not only avoid the maintenance problems and structural requirements of some other mechanisms, but also combine forms of crosscutting so that all the mechanisms for a particular concern are one piece of code.

There are many recent proposals for programming languages that provide control over crosscutting concerns. Aspect-oriented programming is an overall framework into which many of these approaches fit. AspectJ is one particular instance of AOP, distinguished by the fact that it was designed from the ground up to be compatible with Java.

See the Related Sites page of the AspectJ web site for more information.

Reflective and aspect-oriented languages have an important similarity: both provide programming support for dealing with crosscutting concerns. In this sense reflective systems proved that independent programming of crosscutting concerns is possible.

But the control that reflection provides tends to be low-level and extremely powerful. In contrast, AspectJ provides more carefully controlled power, drawing on the rules learned from object-oriented development to encourage a clean and understandable program structure.

Some features of AspectJ, such as introduction, are related to mixin-based inheritance. But, in order to support crosscutting, a core goal for AspectJ, AspectJ goes beyond mixin-based inheritance.

Firstly, an aspect imposes behavior on a class, rather than a class requesting behavior from an aspect. An aspect can modify a class without needing to edit that class. This property is sometimes called reverse inheritance.

Secondly, a single aspect can affect multiple classes in different ways. A single paint aspect can add different paint methods to all the classes that know how to paint, unlike mixin classes.

So mixin-based inheritance doesn't have the reverse inheritance property, and mixins affect every class that mixes them in the same. If I want to do something like SubjectObserverProtocol, I need two mixins, SubjectPartofSubjectObserverProtocol and ObserverPartof... In AspectJ, both halves of the protocol can be captured in a single aspect.

From a question on the user list:

> Anyone know the connections between AOP and Extreme Programming?
> I am really confused. It seems AOP is a programming paradigm, which
> is the next level of abstraction of OOP. Extreme Programming, however,
> this is a lightweight software development process. One of the common
> motivations of AOP and XP is designed to adopt to the requirement
> changes, so that it can save the cost of software development.
            

This is Raymond Lee's answer:

You're not really that confused. AOP and XP are orthogonal concepts, although AOP can be used to help accomplish XP goals. One of the goals of XP is to respond to changing requirements. Another is to reduce the overall cost of development. These are not necessarily the same thing.

One of the principles of XP that contribute to meeting those goals is to maintain clean, simple designs. One of the criteria for clean, simple designs is to factor out duplication from the code. Benefits of removing duplication include the code being easier to understand, better modularity of the design, lower costs of code changes, less chance of conflicting changes when practicing collective code ownership, etc.

Different types of duplication lend themselves to being addressed by different design paradigms and language features. Duplicate snippets of code can be factored out into methods. Duplicate methods can be factored out to common classes, or pushed up to base classes. Duplicate patterns of methods and their use can be factored out to mechanisms of classes and methods (i.e. instantiations of design patterns).

AOP addresses a type of duplication that is very difficult to handle in the other common paradigms, namely cross-cutting concerns. By factoring out duplicate cross-cutting code into aspects, the target code becomes simpler and cleaner, and the cross-cutting code becomes more centralized and modular.

So, AOP as a paradigm, and the associated tools, gives an XPer, or anyone wanting to remove duplication from the code base, a powerful way to remove a form of duplication not easily addressed until now.

Not at this time. Although the resemblances between C# and Java means it would probably be a fairly straightforward matter to take the AspectJ language design and produce AspectC#, our current focus is only on supporting effective uses of AspectJ.

You may use AspectJ in your product or project with little risk. Several factors play a role in reducing the risk of adopting this new technology:

Using aspects reduces, as a side effect, the number of source lines in a program. However, the major benefit of using aspects comes from improving the modularity of a program, not because the program is smaller. Aspects gather into a module concerns that would otherwise be scattered across or duplicated in multiple classes.

The issue of performance overhead is an important one. It is also quite subtle, since knowing what to measure is at least as important as knowing how to measure it, and neither is always apparent.

There is currently no benchmark suite for AOP languages in general nor for AspectJ in particular. It is probably too early to develop such a suite because AspectJ needs more maturation of the language and the coding styles first. Coding styles really drive the development of the benchmark suites since they suggest what is important to measure.

In the absence of a benchmark suite, AspectJ probably has an acceptable performance for everything except non-static advice. Introductions and static advice should have extremely small performance overheads compared to the same functionality implemented by hand.

The ajc compiler will use static typing information to only insert those checks that are absolutely necessary. Unless you use 'thisJoinPoint' or 'if', then the only dynamic checks that will be inserted by ajc will be 'instanceof' checks which are generally quite fast. These checks will only be inserted when they can not be inferred from the static type information.

If you'd like to measure the performance be sure to write code fragments in AspectJ and compare them to the performance of the corresponding code written without AspectJ. For example, don't compare a method with before/after advice that grabs a lock to just the method. That would be comparing apples and oranges. Also be sure to watch out for JIT effects that come from empty method bodies and the like. Our experience is that they can be quite misleading in understanding what you've measured.

Well I haven't yet seen a language in which you can't write bad code!

But seriously, most AspectJ users find that just like when they learned OO, it takes a while to really get the hang of it. They tend to start in the usual way, by copying canonical examples and experimenting with variations on them.

But users also find that rather than being dangerous, AspectJ helps them write code that is more clear and has better encapsulation -- once they understand the kind of modularity AspectJ supports. There are several good papers that talk about this (see below), but here's a basic point to keep in mind: when properly used, AspectJ makes it possible program in a modular way, something that would otherwise be spread throughout the code. Consider the following code, adapted from the AspectJ tutorial:

aspect PublicErrorLogging {
    Log log = new Log();

    pointcut publicInterface(Object o):
        call(public * com.xerox.*.*(..)) && target(o);

    after(Object o) throwing (Error e): publicInterface(o) {
        log.write(o, e);
    }
}
          

The effect of this code is to ensure that whenever any public method of an interface or class in the com.xerox package throws an error, that error is logged before being thrown to its caller.

Of course in the alternative implementation a large number of methods have a try/catch around their body.

The AspectJ implementation of this crosscutting concern is clearly modular, whereas the other implementation is not. As a result, if you want to change it, its easier in the AspectJ implementation. For example, if you also want to pass the name of the method, or its arguments to log.write, you only have to edit one place in the AspectJ code.

This is just a short example, but I hope it shows how what happens with AOP and AspectJ is that the usual benefits of modularity are achieved for crosscutting concerns, and that leads to better code, not more dangerous code.

One paper someone else just reminded me of that talks some more about this is: http://www.cs.ubc.ca/~kdvolder/Workshops/OOPSLA2001/submissions/12-nordberg.pdf

In the spirit of Smalltalk, we have decided to give more power to the language in order to let the user community experiment and discover what is right. To date this has proven to be a successful strategy because it has permitted the construction of many useful aspects that crosscut the internal state of an object, and as such need access the its private members. However, we are not discounting that some sort of restrictions are useful, rather, we are seeking input from the community in order to decide on what these restrictions should be.

In that light, our position on encapsulation is :

Introducing parents or members to classes is a well-studied OO technique known as open classes.

Open classes have been used in many languages prior to AspectJ, including CLOS, Python, Smalltalk, Objective-C, and others. Building from Java, introduction in AspectJ provides better name hygiene and access control than prior languages. Introduced code obeys all of Java's normal accessibility rules for its lexical location in the aspect that it is introduced from. Such code can not even see, much less access, private members of the class it is introduced into. Further, introductions can be declared private to the aspect, so they are not visible to other clients of the class.

Privileged aspects do permit access to private members of another class. They are a response to the very few cases where developers genuinely need such access (typically for testing purposes where it access is necessary), but it would be more risky to open access by putting the aspect in the same package, adding test code, or changing access in the target class. We recommend using privileged aspects only as necessary, and believe that marking them "privileged" makes any potential misuse apparent.

Let's consider some of the major component types in J2EE:

The basic limitations are that there is no built-in support for writing J2EE analogs for AspectJ extensions to Java, like distributed aspects, distributed cflow, or managing state between invocations. These don't prevent one from using AspectJ to do useful intra-component implementation, nor need they prevent one from building distributed support, state management, and inter-component implementations that leverage AspectJ. It just takes some work. In more detail:

One limitation in current AspectJ support for J2EE is that the current ajc compiler, operates (only) over code the compiler controls.

Some advice on EJB operations will generate methods that confuse ejb compilers. To avoid this problem, you can use the -XaddSafePrefix flag when compiling with ajc.

EJB components may be invoked remotely, and containers may passivate and pool EJB's. Servlets have similar limitations, and in both cases the lifespan of the defining class loader is implementation-dependent (though it must span the operation of a particular request).

The current AspectJ implementation supports aspects that operate through non- remote invocations during the lifetime of the namespace for a particular deployment unit compiled in its entirety by the ajc compiler. This means AspectJ supports common aspects only within a single local runtime namespace (usually implemented as a class loader hierarchy).

Further, AspectJ recognizes language-level join points (object initialization, method calls, etc.), not their EJB analogs (ejb find or create methods...). These lead to the following consequences:

In addition, any AspectJ code should respect EJB operations:

At this time, unfortunately not. The two compilers are just not at all compatible. In an ideal world, there would be a wonderful Open Source extensible compiler framework for Java that both GJ and AspectJ would be built on top of, and they would seamlessly interoperate along with all other extensions to Java that you might be interested in, but that's not the case (yet?).

However, on 09 October 2000, the Java Community Process approved a proposal to add generic types to Java that is largely based on GJ (JSR 14). A draft specification was submitted for public review, which closed on 01 August 2001, and a prototype implementation has been released.

We are committed to moving very rapidly to add support for generic types in AspectJ when generic types become part of the Java language specification. Everyone on the AspectJ team is looking forward to this, because we too would really like to be able to write code that includes both aspects and generic types.

The AspectJ users mailing list provides an informal network of AspectJ experts. To subscribe, visit the Mailing Lists page of the AspectJ web site.

If you have a problem that is not a bug, you may email the AspectJ team at support@aspectj.org. You may view and submit bug reports and feature requests at http://aspectj.org/bugs.

Members of the AspectJ team are available to work with users in more depth on both program design and implementation issues. The team also presents educational courses and speakers for interested groups and offers commercial support and consulting for businesses. Please contact the AspectJ team. with your request.

You need to specify to the compiler the source files that contain your aspects and the source files that contain the types affected by your aspects. See Q: How do I know which aspects affect a class when looking at that class's source code?. The AspectJ compiler will not search the source path for types that may be affected (unlike Javac and Jikes), and it only uses aspects in source form.

In some cases you should compile your entire system all at once. If this is too slow, then you can try to make reasonable divisions between sets of source files whose aspects do not interact to achieve a shorter compile cycle (particularly for development aspects). However, if you get any problems or if you wish to run tests or do a release, you should recompile the entire system.

Yes, use the argfile option to ajc. List source files in a line-delimited text file and direct ajc to that file using -argfile or @:

ajc @sources.lst
ajc -argfile sources.lst
          

For more information, see the ajc tool section of the Development Environment Guide .

Use the latest, greatest, fastest JVM you can get your hands on for your platform. The compiler's performance is dependent on the performance of the JVM it is running on, so the faster a JVM you can find to run it on, the shorter your compile times will be. At a minimum you need to use a Java 2 or later JVM to run the compiler. We realize that this constraint can be a problem for users who are running on Macintosh (until OS X in early 2001) and FreeBSD that don't currently have a Java 2 JVM available. We're sorry for the inconvenience, but we had to make the hard decision that the advantages of being able to rely on Java 2 were worth the cost of losing a number of developers who are working on platforms without Java 2 support. Here is a list of starting places where you might find support for your system.

The requirement of Java 2 support is only for running the AspectJ compiler. The AspectJ compiler can be used to build programs that will run on Java 1.1 (or probably even on Java 1.0) systems. This means that it can build programs that will run on Macintosh, FreeBSD, and applets that will run in Internet Explorer and Netscape Navigator that are still not yet Java 2 compliant.

ajc can be used to develop programs that are targeted at the Java 1.1 platform, even though the ajc compiler won't run on that platform. Here's an example of using ajc in this sort of cross-compilation mode (assuming a Windows platform with all the default installation directories):

ajc -target 1.1 -bootclasspath c:\jdk1.1.7\lib\classes.zip \
   -classpath c:\aspectj1.0\lib\aspectjrt.jar -extdirs "" \
   -argfile jdk11system.lst
          

This same technique can be used if you want to run ajc on a JDK 1.3 JVM (highly recommended) but need to generate code for JDK 1.2. That would look something like:

ajc -bootclasspath c:\jdk1.2\jre\lib\rt.jar \
   -classpath c:\aspectj1.0\lib\aspectjrt.jar \
    -extdirs c:\jdk1.2\jre\lib\ext
            -argfile jdk12system.lst
          

Yes. As with Javac, use the -source 1.4 option as described in the ajc tool section of the Development Environment Guide .

Since AspectJ requires Java 2 or later, it will not run on the Microsoft JVM, which does not support Java 2.

No. Some previous versions of AspectJ had this requirement, and javac can still be used as ajc back end by using the -usejavac flag. You can also run ajc in preprocessor mode to generate Java source (.java) files to be compiled using javac or another java compiler.

The PARSER for ajc is written by hand. This choice was made with full awareness of the generator tools out there. (Jim had for example used the excellent javacc tool for building the parser for JPython (now Jython)). One of the reasons that AspectJ uses a hand-written parser is that using javacc taught Jim about the LL-k design for parsers (pioneered by antlr). As opposed to the state-machine parsers produced by yacc, these parsers are very readable and writable by humans.

Antlr and javacc did not really suit the project:

There were also several things that were easier to implement with a hand-written parser than with any of the exiting tools.

When you are working with the IDE support, you can get an understanding of which aspects affect any class. This enables AspectJ programmers to get the benefits of modularizing crosscutting concerns while still having immediate access to what aspects affect a class.

For example, the Development Environment Guide section on ajbrowser shows that you can list or navigate between method and advice affecting that method and between a type and declarations in an aspect on that type. (The IDE support may have more features than ajbrowser, depending on the IDE.)

When you are looking at documentation, ajdoc will provide links from aspects and advice to the affected code, but it provides less information than the IDE support because it only parses declarations.

When you are running your program, you can trace advice as it executes. This enables you to identify advice on join points picked out dynamically, which cannot be reflected precisely by IDE support.

See Q: How well does AspectJ integrate with existing Java development tools? for more information on which Java development environments are supported.

See Q: How well does AspectJ integrate with existing Java development tools?

If you are using development-time-only aspects - aspects that only exist when you are developing the code, not when you ship it - you can use implement a hybrid build process by listing the production source files into a javac-compliant argfile, and the development source files in another ajc argfiles:

     -- file "production.lst":
     One.java
     two/Three.java
     ...

     -- file "tracing.lst":
     trace/Library.java
     Trace.java

     -- file "development.lst":
     @production.lst
     @tracing.lst
          

Then your development build can use ajc:

            ajc @development.lst
          

And your development build can use ajc or javac or jikes:

            jikes @production.lst
          

IDE support depends on a workable extensibility API in the IDE, a significant community of users, and our limited time. The following IDEs are being considered for future support:

If you would like to build support for another IDE, please contact us so we can help.

To contribute, propose new IDE's, or promote particular IDE's under consideration, please mail us.

Yes. The core AJDE API is extensible and the source code is available for download. Since porting documentation is limited, the best way to approach extending support is by studying the sources for the existing IDE support.

AspectJ does not enable you to change the signature of a method, but you can (by express declaration) work around some limits imposed by the signature. You can convert a checked exception to unchecked using declare soft, privileged aspects have access to private methods, and you can use a percflow aspect to ferry additional state to a callee without changing intervening signatures. For more details, see The AspectJ Programming Guide. In the case of synchronized, we have what we consider a better solution that uses around advice instead of introduction. This solution is described in this thread on the AspectJ users list, with some additional comments .

Try using an aspect posted to the user's list called TraceJoinPoints.java . For example, you can start logging at a particular method call and see what join points occur after the call and before it returns.

Consider method execution in Java as (1) the initial call from this object to some method on the target object with a particular signature; and (2) the execution of the actual code in the particular method dispatched in the target object. The call join point starts with the initial call and ends when control returns to the call (by return or perhaps thrown exception). The execution join point starts with the method body and ends when the body completes (again by return or throwing an exception), so the execution join point always happens within the bounds of the corresponding call join point. You can see this if you use the join-point tracing aspect in TraceJoinPoints.java . as described above.

As you would expect, the context differs in advice on pointcuts picking out execution and call join points; for call, this refers to the caller, whereas for execution this refers to the called (executing) object.

There are some subtle interactions with other AspectJ semantics. First, the meaning of the signature in the execution() and call() pointcut designators (PCD's) differ: the call type depends upon the type of the reference making the call, while the execution type depends on the enclosing class. Second, you may choose one over another if you cannot bring all your sources within the code the compiler controls (described in the appendix to the Programming Guide). For example, to trace calls into a method from classes which are outside the code the compiler controls at compile time, then using execution() will work while using call()may not. Finally, since super invocations are not considered method calls, to trace super.foo() would require using execution.

In most cases you should use the call() pointcut designator unless you have a good reason to use execution()

Both pick out all the join points in the control flow of the specified join points. They differ only in that the cflowbelow() pointcut designator does not pick out the join points specified, while cflow() does.

There are two interesting times when a constructor or method is run. Those times are when it is called, and when it actually executes.

The main difference is that a call join point happens outside of the object (for non-static methods) or class (for static methods and constructors), and that an execution join point happens inside the object or class. This means that the within and withincode pointcuts pick them out differently: A call join point is picked out within the caller, while an execution join point is picked out where it is actually defined.

A call join point is the ``outermost'' join point for a particular call. Once a call join point proceeds, then a number of different things happen. For non-static methods, for example, method dispatch happens, which will cause one method execution join point -- perhaps more, if there are super calls. For constructors, the super constructor is called, and fields are initialized, and then various constructor execution join points will occur.

A call join point matches only the ``external'' calls of a method or constructor, based on a signature, and it does not pick out calls made with super, or this constructor calls.

This is best seen by way of example. Given a recursive call to int factorial(int) you can print the arguments for (a) the current and most-recent recursive call or (b) the current and original recursive call:

aspect LogFactorial {
    pointcut f(int i) : call(int factorial(int)) && args(i);

    // most-recent
    before(int i, final int j) : f(i) && cflowbelow(f(j)) { 
        System.err.println(i + "-" + j);
    }

    // original
    before(int i, final int j) : f(i) 
        && cflowbelow(cflow(f(j)) && !cflowbelow(f(int))) { 
        System.err.println(i + "@" + j);
    }
}
          

Static initialization pertains to initialization of a class or interface type. Constructor call and execution are akin to method call, and initialization generalizes this and picks out the first constructor called.

Their relations are best demonstrated by tracing the join points. Below is the class Test which implements an interface and extends a class along with a trace of the join points below and including the constructor call obtained using TraceJointPoints.java (linked above).

            
public class Init {
    public static void main (String[] args) {
        new Test(); 
        end();
    } 
    static void end() {}
}
class Super {}
interface I {}
class Test extends Super implements I {
    Test() {}
}

  <constructor-call sig="Test()" >
    <staticinitialization sig="Super._init_" />
    <staticinitialization sig="Test._init_" />
    <initialization sig="Super()" >
      <instanceinitializer-execution sig="Super._init_" />
      <constructor-execution sig="Super()" />
    </initialization>
    <initialization sig="I()" >
      <instanceinitializer-execution sig="I._init_" />
      <constructor-execution sig="I()" />
    </initialization>
    <initialization sig="Test()" >
      <instanceinitializer-execution sig="Test._init_" />
      <constructor-execution sig="Test()" />
    </initialization>
  </constructor-call>

          

Ordinarily, using a call pointcut designator is best because the call join point surrounds the others, but in the case of constructors there is no target object for the call (because it has not been constructed yet), so you might prefer to use the initialization pointcut designator.

There is no way in advice to refer to the type of the code executing in a static context except by specification. This makes it impossible to refer to static members using runtime information.

No. You can declare that all the types implement an interface you define, and then use the interface type in your program. For example:

/** 
 * Example of using an interface to represent a type pattern.
 * sub-aspects use declare parents to add to traced types, e.g.,
 *    declare parents: com.mycompany.whatever..* implements Marked;
 */
abstract aspect MarkerExample {
  /** marker interface for types that we want to trace */
  interface Marked {}

  /** calls to an instance of Marked not from an instance of Marked */
  pointcut dynamicCallsIn(): call(* *(..)) && target(Marked) && !this(Marked);

  /** calls to methods defined by a subtype of Marked
   *  that don't come from the body of a subtype of Marked
   */
  pointcut staticCallsIn(): call(* Marked+.*(..)) && !within(Marked+);

  /** print dynamic calls */
  before(): dynamicCallsIn() { System.out.println("before " + thisJoinPoint); }
}

aspect MyMarker extends MarkerExample {
  declare parents: com.mycompany.whatever..* implements Marked;
}
          

Some examples are distributed in the documentation release, and you can find other code in the discussions on the users list.

Some libraries are distributed in the release under the examples folder in the distribution. If you develop a library and want to make it available to other users, make sure to contact us .

The current version of ajc can change the serialVersionUID of generated .class files as a result of weaving in advice. This is an important fact that developers using both aspects and serialization should be aware of. It is likely that a future version of the compiler will be better behaved regarding the serialVersionUID.

However, changes to the serialVersionUID attribute are typically only important when using serialization for the long-term persistence of objects. Using standard Java serialization for long-term persistence has a number of drawbacks and many developers already use alternative solutions. For one possibly standard solution, see Lon g-Term Persistence for JavaBeans Specification .

Most likely this is a case of infinite recursion, where advice is advising itself. It presents as a StackOverflowError or silence as the VM exhausts itself in the recursion.

Of course, infinite recursion is possible in Java:

public class Main {
    public static void main(String[] args) {
        try {
           main(args);
        } finally {
           main(args);
        }
    }
}
          

If you compile and run this program, and it will fail silently, trying to process the finally clause even after throwing the StackOverflowError.

Here's a similar AspectJ program where the recursion is not so obvious:

aspect A {
    after():  call(* *(..)) { System.out.println("after " + thisJoinPoint); }
}
          

This re-invokes itself because it advises any call. It invokes itself even after an exception is thrown, since after advice, like a finally clause, runs even after exceptions are thrown. You can fix this by following two practices:

(1) Use after returning to advise normal completions or after throwing to advise abrupt completions. If you use after or after throwing, write the advice with the same care you would a finally clause, understanding that it may run after some failure.

(2) Avoid writing advice that advises itself. One simple way to do so is to exclude the code within the current aspect:

aspect A {
    after() returning:  !within(A) && call(* *(..)) { 
        System.out.println("after " + thisJoinPoint); 
    }
}
          

A better way is often to re-write the pointcut. If the advice is advising itself accidentally, that's a sign that the pointcut is not saying what you mean.

aspect A {
    pointcut withinTargetClasses() : within(A+) || within(B+);
    after() returning:  withinTargetClasses() && call(* *(..)) { 
        System.out.println("after " + thisJoinPoint); 
    }
}
          

You need a type to refer to any member, field or method. It's generally better to introduce onto an interface and declare classes to implement the interface, which permits you to use the interface type in advice formals.

aspect A {
    interface TrackingSets {}
    boolean TrackingSets.dirtyFlag;
    declare parents : com.xerox..* implements TrackingSets;

    after (TrackingSets target) returning 
        : target(target) && call(* com.xerox..*.set*(..)) {
        target.dirtyFlag = true; 
    }
}
          

The command ajc is actually a script that launches a Java virtual machine with the correct classpath. You should make a copy of this script, rename it, and then edit it. Change the -Xmx option, size of memory allocation pool (heap). You might try -Xmx128M or even -Xmx256M.

ajc 1.0 does not currently support incremental compilation, but we are working on this for the 1.1 release.

As a limited workaround, many build systems enable you to avoid doing a compile if no sources have changed. (See, e.g., Ant's "uptodate" task.)

The easiest way to fix this is to re-install ajc (using the same .class or .exe file that you originally downloaded) and this time make sure to tell it to use the desired JDK (typically the JDK versions 1.2 or 1.3 from Sun).

If you are familiar with DOS batch files or shell programming, you could also fix this by simply editing the bin\ajc.bat or bin/ajc script.

When working with an unsupported IDE that objects to the syntax of AspectJ source files (and, e.g., automatically gathers them in a source tree as Java files based on the .java extension), you can use the .aj extension for your AspectJ files. The ajc compiler accepts both .java and .aj files, and you can set up your build scripts to include the correct list of source files. (You will have to find another editor for editing AspectJ files; you can use the ajbrowser to view edit your AspectJ files and navigate the crosscutting structure.)

Unless you are using the ajdb debugger, stack traces may have synthetic methods in the stack, and the line numbers may not track your source code. The Development Environment Guide. discusses how to interpret stack at the end of the section on the ajc compiler.

When advice is not running, it is probably a problem in the pointcut. Sometimes users specify pointcuts that do not mean what they intend - most often when they misspell a type name. Run the compiler in -Xlint mode, which will flag some likely mistakes, like the type name. If that does not work, use TraceJoinPoints.java to see if your join points are executing at all.

When advice is running more than it should, it may be that your pointcut picks out more join points than you intend. If you are using IDE support, you should be able to trace back from the pointcut or advice to the join points which can be statically determined to be affected. To identify advised dynamic join points, you can try using TraceJoinPoints.java , but often it is easier to update the advice to print the source location of the join point. This will show if the advice applies to to code that you did not consider.

If you've done this and convinced yourself it's not working, it may be a bug. See Q:How do I submit a bug report?.

ajc does not try to locate javac in your path: it uses the javac classes directly. In JDK 1.2 and 1.3 these classes are found in tools.jar (in the lib directory of the JDK distribution), which must be on your classpath to make ajc work with javac. Inspect the java command that launches ajc to make sure that tools.jar is on the classpath for ajc; the -classpath option only applies to the sources compiled.

The current implementation of ajdoc uses specific javadoc classes in the J2SE 1.3 tools.jar. We are working on addressing this limitation, but in the interim it is best to run ajdoc under 1.3.

It is a bad practice to use the compilation unit to control crosscutting. Aspects and pointcuts especially should be written to specify crosscutting precisely. Aspects will behave the same when you add files if you initially included all files affected by your aspects. If you use the compilation unit, then your code will behave differently in AspectJ implementations that do not limit themselves to specified files.

The generated code can be difficult for a human to read and understand. The compiler uses implementation techniques which might not be apparent. To determine if the code is behaving correctly, you should write and run a program that attempts to provoke the error you suspect. Similarly, you should not rely on invariants you infer from the generated code (especially naming conventions for generated members). Please rely only on the semantics stated in the appendix of the AspectJ Programming Guide.

This is a misconception spawned from the early implementation.

AspectJ does not "inject" or "generate" code. In AspectJ the pointcut constructs allow the programmer to identify join points, and the advice constructs define additional code to run at those join points.

So the semantic model of advice is like the semantic model of a method -- it says "when any of these things happen, do this".

People who worked with earlier versions of AspectJ, in which ajc was very explicitly a pre-processor, sometimes thought of AspectJ as injecting code. But that was an artifact of the implementation, not the underlying language semantics.

This distinction is important for two reasons. One is that thinking about it this way will make more sense at the implementation continues to evolve towards load-time or runtime weaving. The other is that it makes it much easier to understand the semantics of advice on cflow pointcuts.

Visit the AspectJ website .

You can submit a bug using the web interface (preferred), or you may send email to jitterbug@aspectj.org directly. If it seems to be a bug in the compiler, please include in the body of the email source code to reproduce the problem.

You can email comments to all users at users@aspectj.org, email the AspectJ team at support@aspectj.org. You can view and submit bug reports and feature requests at http://aspectj.org/bugs. If you think you might simply be making a mistake, you might email some source code to users@aspectj.org.

You can reach other AspectJ users by using the aspectj-users mailing list. To subscribe to the list or view the list archives go to the user community page.

For language questions and potential compiler bugs, describe what you are trying to do and provide a code sample, with expected and actual output (if any). Use the concepts, syntax, and semantics shown in the AspectJ Programming Guide . The code is key to clarifying your question and getting a good response. On the mail list, someone can reply by fixing your code. In bugs, the developers can reproduce the problem immediately and start analyzing the fix.

For the mail lists, we try to follow the conventions for open-source discussions that help avoid "the tragedy of the commons." For example conventions, see http://jakarta.apache.org/site/mail.html and http://www.tuxedo.org/%7Eesr/faqs/smart-questions.html.

The documentation available on this site is a primary source of material on AspectJ:

Beyond what's available on the aspectj.org web site, the AspectJ team does a limited amount of consulting and support for qualified groups. For more information, see Q: What kind of support is available?.

There are two philosophies in the Open Source community about when to do the first Open Source release of a system. One philosophy says "release early and release often". The current AspectJ source code release is based on that philosophy. This approach has the wonderful property of offering no excuses for delaying a release until things are "just right" which can often mean never releasing the source code at all.

The other philosophy says that you shouldn't make an Open Source release until the sources are relatively clean, and the core design of the system is relatively stable. This approach makes it much easier for outside developers to make significant contributions to the project. We believe that clean sources and a stable design is an admirable goal for any software project, but we don't want to delay making an Open Source release of AspectJ until we reach that point.

Instead we're just going to include this warning:

AspectJ is a new kind of programming language, and our understanding of how best to design a compiler for it is rapidly evolving. We plan to continually improve and frequently redesign the compiler as our understanding of AOP improves. We expect that the class hierarchies, method names, and fundamental design of the whole system will be significantly changing on a monthly or even weekly basis. No effort whatsoever will be spent at this point in the project to make new versions of the compiler even vaguely resemble a previous release in terms of internal design (Note: we will spend considerable effort to ensure that the compiler will behave in a consistent fashion externally to users of previous versions) .

We expect this period of rapid development to end at some point. We'll be sure to announce it very clearly when we think the basic internal structure of the compiler is relatively stable and we believe it would be a reasonable platform for outside developers to look at and contribute to. Until we make that announcement, well, you've been warned.

So, given that warning, what good is the Open Source release?

Although we are committed to making AspectJ available to a wide range of users, it is too early to decide on a strategy. Some options include continuing AspectJ as a stand-alone product, integrating it into IDEs, or possibly incorporating it into standard Java with Sun's blessing.

We currently focus on increasing quality for the 1.0 releases and improving the AspectJ compiler in key areas: rapid incremental compilation, bytecode weaving, IDE integration and J2EE support. We will also be increasing AspectJ-specific support in AJDE for popular IDEs.

Through all of this our goal is to make AspectJ integrate as seamlessly as possible with the Java programming language. The AspectJ language design is becoming more integrated, the compiler is becoming faster and more integrated, the IDE extensions are becoming more integrated. All of this is designed to help users really use AspectJ and give us feedback on it.

As the system is improved and we work more closely with users, we will be better positioned to explore the best path for long-term AspectJ support.

From an email to the users list by Jim Hugugin:

The AspectJ language was designed to support weaving at many different times: compile, load, or even run-time in the JVM. Weaving into bytecodes at both compile and load-time will definitely be provided in a future release. This will allow weaving at compile-time into libraries for which source code is not available. It will also support aspect-aware class loaders that can perform weaving at load time on arbitrary classes. One advantage of a language like AspectJ, rather than an explicit meta-tool like jiapi, is that it separates the specification of a crosscutting concern from any particular implementation strategy for weaving.

Note: we see the value of these meta-tools for implementing a given weaving strategy. We are looking at several existing meta-tools to simplify the process of bytecode weaving. The current front-runner for us is BCEL, which recently moved to Apache.

Bytecode weaving is not available today because we've focused our development resources on language issues. For many years programmers have been using meta-programming techniques to better capture crosscutting concerns. These techniques are very powerful; however, by working at the meta-level they typically sacrifice some of the good software engineering properties of a base-level language. AspectJ provides a language that can cleanly capture crosscutting concerns while preserving the static type checking, modularity, and composability of Java.

If you have an application for using aspects and bytecode, please let the AspectJ team know of your requirements.

Version	Description
AspectJ 1.0	Many language changes, fixes, cleanup and clarifications, some significant.
AspectJ 0.8	More cleanup of the syntax and semantics.
AspectJ 0.7	Clean up of the semantics, 0.7 beta 4 is the first open source release.
AspectJ 0.6	Advice and crosscuts get explicit type signatures which describe the values that are available to advice at a crosscut.
AspectJ 0.5	Improved tool support: better Emacs environment support and ajdoc to parallel javadoc. around advice is added, and the aspect keyword is removed and replaced by the Java keyword class.
AspectJ 0.4	Clear separation of crosscuts and crosscut actions makes it possible to define extensible library aspects.
AspectJ 0.3	First all Java implementation, also includes many small language improvements.
AspectJ 0.2	General-purpose support for crosscutting. Users could program any kind of aspects, not just coordination. This release dropped COOL.
AspectJ 0.1	A single domain-specific aspect language, called COOL, for programming coordination in multi-threaded programs.

More detailed comments are available in the doc/changes.html file in the distribution.

Version	Description
1.0	Final syntax and semantic changes. All known compiler bugs squashed. Bytecode compilation. Standalone structure browser. Complete documentation
1.1	Faster incremental compilation
2.0	New, dynamic crosscuts (bytecode-only)