AspectJ FAQ

Q: What is AspectJ?

A: 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.

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

The AspectJ technologies include a compiler (ajc), a debugger (ajdb), a documentation generator (ajdoc) and integration with Eclipse and Ant.

Q: What are the benefits of using AspectJ?

A: 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.

Q: Can AspectJ work with any Java program?

A: 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.

Q: How is AspectJ licensed?

A: Since AspectJ 1.9.7, source code and documentation is available under the Eclipse Public License v 2.0.

AspectJ 1.5.2 through 1.9.6 source code and documentation is available under the Eclipse Public License v 1.0.

AspectJ 1.1 through 1.5.1 source code and documentation is available under the Common Public License 1.0.

The AspectJ 1.0 tools are open-source software available under the Mozilla Public License 1.1. That documentation is available under a separate license that precludes for-profit or commercial redistribution.

The runtime jar aspectjrt.jar and its distribution are also covered by the Eclipse Public License.

For answers to common licensing questions, see the Eclipse Public License FAQ.

Q: What is the AspectJ Project?

A: 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 and now operates as an open source project at https://eclipse.org/aspectj 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.2 which can be downloaded from the AspectJ project page, including sources as described Q:How do I get and compile the source code for AspectJ?. Development is focused on supporting applications, improving quality and performance, enhancing integration with IDE’s, and building the next generations of the language.

Q: What Java versions does AspectJ require and support?

A: 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 (< 100K) runtime library (aspectjrt.jar) from the distribution. The tools themselves require J2SE 1.3 or later to run, but the compiler can produce classes for any 1.1-compliant version of the Java platform.

Q: How do I download and install AspectJ?

A: From AspectJ’s web page , download the AspectJ distribution. The jar file is installed by executing

Do not try to extract the jar file contents and then attempt to execute java org.aspectj.tools.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.

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. Do not install over prior versions, which might have different files. Delete the prior version first.

Q: How should I start using AspectJ?

A: Many users adopt AspectJ in stages, 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.

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

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

AspectJ provides replacements for standard Java tools:

For debugging, AspectJ supports JSR-45, which provides a mechanism for debugging .class files that have multiple source files. Debugger clients and VM’s are beginning to support this; see Sun’s J2SE 1.4.1 VM and jdb debugger and recent versions of JBuilder.

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 extend some of their development practices without having to abandon their existing tools.

AJDE is a set of API’s providing the basis for the following development tool integrations:

Finally, as mentioned above, AspectJ also supports building with Ant by providing task interfaces to the ajc and ajdoc tools.

Q: Are aspects always optional or non-functional parts of a program?

A: 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,

Q: What is the difference between development and production aspects?

A: 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.

Q: What are some common development aspects?

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

Q: What are some common production aspects?

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

Q: What are scattering, tangling, and crosscutting?

A: "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.

Q: What are join points?

A: 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.

Q: What is a pointcut?

A: A pointcut picks out #q:joinpoints[ 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.

Q: What is advice?

A: Advice is code that executes at each #q:joinpoints[join point] picked out by a #q:pointcut[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.

Q: What are inter-type declarations?

A: 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.

Q: What is an aspect?

A: 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…​

Q: Are crosscutting concerns induced by flaws in parts of the system design, programming language, operating system, etc. Or is there something more fundamental going on?

A: 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.

Q: Does it really make sense to define aspects in terms of crosscutting?

A: 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 were once available at https://www.cs.ubc.ca/~gregor/vinst-2-17-01.zip.)

Q: Is AOP restricted to domain-specific applications?

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

Q: Why do I need AOP if I can use interceptors (or JVMPI or ref lection)?

A: 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.

Q: How does AspectJ compare to other new forms of programming?

A: 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.

Q: How do you compare the features of AspectJ with reflective systems?

A: 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.

Q: How do AspectJ features compare with those of mixin-based inheritance?

A: 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.

Q: How does AspectJ compare with more dynamic AOP?

A: Some AOP techniques are presented as "dynamic" because the weaving occurs when classes are loaded, because aspects can be configured in a separate XML file before launch, or because some advice depends on runtime reflection. They are said to be more flexible than AspectJ.

This is a misconception. First, the AspectJ 1.1 weaver has always supported weaving at compile-time or class-load-time. Weaving at compile-time reduces application launch and running time, and it helps IDE’s offer support for tracking down weaving errors and understanding the impact of aspects on a system. On the other hand, weaving at load-time simplifies build and deployment. Before AspectJ 1.2, the user had to write a class loader that used the weaver API to weave at load time; since 1.2, AspectJ comes with a command-line launcher to support weaving at class-load-time without any other changes to a build configuration. In AspectJ 5, we expect to get a similar level of support as AspectWerkz, and to exploit the class bytecode weaving hook available in Java 5 VM’s.

Second, AspectJ programs, like Java programs generally, can be written to support any level of XML configuration or to depend on runtime reflection. There are some benefits to using AspectJ; e.g., the proceed() form within around advice simplifies a lot of the work that otherwise would go into writing a generalized interceptor, without introducing many of the runtime errors that can result from interceptors. For AspectJ examples of configurable or reflection-dependent programs, see the sample code linked off the AspectJ documentation page or the examples discussed on the mailing list, e.g., Incremental and runtime weaving support?.

Q: What is the relationship between AOP and XP (extreme programming AKA agile methods)?

A: From a question on the user list:

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.

Q: Will you support C#?

A: 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.

Q: Is it safe to use AspectJ in my product plans?

A: 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:

Q: What is the effect of using AspectJ on the source code size of programs?

A: 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.

Q: Does AspectJ add any performance overhead?

A: 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.

We aim for the performance of our implementation of AspectJ to be on par with the same functionality hand-coded in Java. Anything significantly less should be considered a bug.

There is currently no benchmark suite for AOP languages in general or 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.

Though we cannot show it without a benchmark suite, we believe that code generated by AspectJ has negligible performance overhead. Inter-type member and parent introductions should have very little overhead, and advice should only have some indirection which could be optimized away by modern VM’s.

The ajc compiler will use static typing information to only insert the advice and dynamic pointcut tests that are absolutely necessary. Unless you use 'thisJoinPoint' or 'if', the main dynamic checks 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.

When measuring performance, write AspectJ code fragments 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.

Q: I’ve heard that AspectJ leads to modularity violations. Does it?

A: 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:

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: https://www.cs.ubc.ca/~kdvolder/Workshops/OOPSLA2001/submissions/12-nordberg.pdf

Q: Why does AspectJ permit aspects to access and add members of another type? Isn’t that violating OO encapsulation?

A: 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.

Q: Can I use AspectJ with J2EE?

A: Consider the 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-container 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:

All AspectJ implementations may define "code the implementation controls". The AspectJ 1.0 implementation defines this as the files passed to the compiler (AspectJ 1.1 will also support bytecode weaving).

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).

Being limited by lifecycle and namespace, the AspectJ 1.0 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:

Q: Can I use AspectJ with Generic Java?

A: We plan to support Generics when Java 1.5 is available.

But 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 by Sun.

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.

Q: Can I use AspectJ with J2ME?

A: The J2ME platform has several different components. The diagram below shows how the different profiles build on top of the two configurations CDC (Connected Device Configuration) and CLDC (Connected Limited Device Configuration):

Which configuration you have dictates the restrictions when running AspectJ compiled programs.

If you’re running with a profile which sits on top of CDC then there are not, as far as we are aware, any restrictions when running AspectJ compiled code on this flavour of J2ME.

If you’re running with a profile sitting on top of CLDC 1.1 you are currently unable to use the thisJoinPoint, thisJoinPointStaticPart and ` thisEnclosingJoinPointStaticPart` variables, the cflow and cflowbelow pointcuts and the percflow and ` percflowbelow` perClauses.

Finally, if you’re running with a profile which sits on top of CLDC 1.0 you have all the restrictions of CLDC 1.1. There may be further restrictions due to the lack of types corresponding to the primitive types (e.g. Integer.TYPE), however, at the time of writing we have been unable to do any extensive testing on this.

Note that the aspectj runtime jar is now (as of AspectJ5) quite large but only a small subset is required for executing code in J2ME environments. We plan to ship a second aspectjrt.jar built for the J2ME environment at some point.

For more discussion and to raise any issues you have with AspectJ and J2ME, refer to bugzilla entry 92933.

Q: Are you working to put AOP into Java? It seems that every AOP toolset currently uses proprietary mechanisms to describe point-cuts, etc.

A: We are working on standardization, but it’s a question of timing/ripeness (imagine going from thousands of users to millions). (See #q:standardization[Q:What are your plans to make AspectJ a general feature of Java supported by Sun and the other key-players in the Java Industry?].) We believe AspectJ addresses this question in the best way possible now:

Q: What kind of support is available?

A: The mailing lists provide the primary support for everyone in the community (See #q:mailingLists[Q: What mailing lists are there?]). To request commercial support, tutorials, or presentations, use the developer mailing list, aspectj-dev@eclipse.org.

To find out about known issues, see the AspectJ Programming Guide Appendix, "Implementation Notes" and the AspectJ bugs in the database at https://bugs.eclipse.org/bugs (using the product AspectJ). Here are direct links to view open compiler bugs, view all Aspectj bugs (open or closed), or add new bugs.

Q: What mailing lists are there?

A: The AspectJ users mailing list (aspectj-users@eclipse.org) provides an informal network of AspectJ language users who can answer usage questions about AspectJ programs and the AspectJ tools. This is the place to ask how to code something in AspectJ or how to write Ant or shell scripts to invoke the tools.

The AspectJ developers mailing list (aspectj-dev@eclipse.org) provides an informal network of AspectJ technology experts who aim to understand the technology behind AspectJ. The committers to the AspectJ project use this list for open technical and planning discussions. Developers can answer questions about what’s possible and about integrating AspectJ technology with other technologies.

For both mailing lists, only subscribed members may post messages. To subscribe, visit the AspectJ web site.

There you can also subscribe to aspectj-announce@eclipse.org, a low-traffic list containing only announcements about significant AspectJ events and product releases.

Q: Do I have to use the AspectJ compiler?

A: The AspectJ compiler or weaver is required at some point, but many people can use AspectJ without changing their build or deployment process significantly. For aspects that are not required to compile, you can use the AspectJ binary weaver, run at build-time or class-load-time. You can write aspects using the original code style (which must be compiled with the AspectJ compiler) or using the annotation style new in AspectJ 5 (which may be compiled with Javac or the AspectJ compiler).

For more information, see #q:codeversusannotationstyles[Q:Should I use code- or annotation-style aspects?].

Q: What files do I need to include when compiling AspectJ programs?

A: You need to specify to the compiler the files that contain your aspects and the files that contain the types affected by your aspects. See #q:knowWhenAspectsAffectClasses[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). In AspectJ 1.0, ajc requires all code to be in source form; in AspectJ 1.1, Java and AspectJ code may be in either source or binary 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). If you have aspects that apply to different modules, you can try compiling them into a binary form and using them to weave each module. However, if you get any problems or if you wish to run tests or do a release, you should recompile the entire system.

For more information, see the Development Environment Guide Reference for ajc.

Q: I have to list many files in the command line to compile with ajc. Is there any other way to provide the file names to ajc?

A: 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 @:

Another way in AspectJ 1.1 is to use the -sourceroots options, which reads all source files in a given set of directories:

For more information, see the Development Environment Guide Reference for ajc.

Q: What Java virtual machine (JVM) do I use to run the AspectJ compiler?

A: 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 (J2SE 1.3 for AspectJ 1.1). We realize that this constraint can be a problem for users who 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.

Q: How can I use ajc to compile programs for a JVM that is different from the one used to run it?

A: 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):

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:

Q: Does the ajc compiler support the assert keyword in Java 1.4?

A: Yes. As with Javac, use the -source 1.4 option as described in the Development Environment Guide Reference for ajc.

Q: Does the ajc compiler support generics and the other new language features of Java 5?

A: Yes. As with Javac, use the -1.5 option as described in the Development Environment Guide Reference for ajc.

Q: Will aspects work with different versions of the compiler/weaver and runtime?

A: Yes. Both ajc and aspectjrt.jar should work with versions of aspect code and libraries back to AspectJ 1.2.1. Any aspects should be deployed with the same version of aspectjrt.jar they were compiled with. For more information, see the Development Environment Guide Reference for ajc and Deployment notes section on Version compatibility.

Q: Are there any issues using AspectJ with the Microsoft JVM?

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

Q: Does ajc rely on javac for generating Java bytecode (.class) files?

A: No. Some previous versions of AspectJ had this requirement. In AspectJ 1.0, 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. Neither option is supported in AspectJ 1.1.

Q: I noticed the AspectJ compiler doesn’t use a parser generator. Why is that?

A: In AspectJ 1.0, 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.

Q: How does incremental mode work?

A: In incremental mode, ajc minimizes the files that need to be recompiled after another file has changed. In Java, only the changed files need to be recompiled, but in AspectJ, other files might also need to be recompiled or re-woven.

Depending on what is modified, we may need to re-weave code. If you change a pointcut and save it, we currently have to check everywhere in case a new match is occurring or an old match is no longer correct. However, if you simply change the body of an advice in an aspect, there is (usually) no need to reweave as the affected classes call the advice and the advice (by design) maintains its name in the recompiled aspect.

If you make a change to a class (as opposed to an aspect) and save it, we usually can get away with merely having to compile that class then weave the existing aspects with it - rather than doing a full recompile of the entire system.

There are a lot of possible optimizations to the algorithms we use, by performing more complete analysis of the change made to a file that will enable us to know more accurately whether we need to reweave and if we do then what we need to reweave - we just haven’t gotten around to implementing them yet.

Q: How do I know which aspects affect a class when looking at that class’s source code?

A: 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 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 that, depending on the IDE. See #q:integrateWithDevTools[Q: How well does AspectJ integrate with existing Java development tools?] for more information on which Java development environments are supported.)

When you are looking at documentation for AspectJ 1.0 programs, 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 compiling your program, pointcuts that are statically-determinable can be used in declare statements to identify the code picked out by the pointcut. (A pointcut is statically determinable if it only uses the pointcut designators within, withincode, execution, call, get, set, initialiation, and staticinitialiation.) The compiler will list the static code points which will be affected by any advice specifying the same pointcut. For example, the following will print a warning whereever some code in class Bar gets a field value from Foo:

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. For a related tracing question, see #q:seeingjoinpoints[Q:I don’t understand what join points exist. How can I see them?]

Q: What kind of IDE support is available for developing AspectJ programs?

A: See #q:integrateWithDevTools[Q: How well does AspectJ integrate with existing Java development tools?]

Q: What plans are there to support my IDE?

A: The AspectJ team directly provided components for JBuilder, Forte, and Emacs and supported the open-source AspectJ plugin project at https://eclipse.org/ajdt which uses the AJDE API support for IDE’s. Supporting new IDE’s is a matter of building on the AJDE API’s, mostly likely adopting one of the existing open-source IDE extensions as a design template. Here are the IDE’s where we know people have expressed interest, so interested developer may want to join with others in their developer communities to build the integration.

For questions on AJDE, join the developer’s list aspectj-dev@eclipse.org. For questions on the current IDE integrations, contact those projects.

Q: Can I port AJDE support to my development environment?

A: Yes. The core AJDE API is extensible and the source code is available for download. Start by studying the sources for the existing IDE support linked off the AspectJ site https://eclipse.org/aspectj.

Q: I want the aspects for development builds but remove them for production builds. How can I set up the build system so they are unpluggable? And so I use javac in my production build?

A: 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:

Then your development build can use ajc:

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

Q: We compile module jars and then assemble them. Can we continue this with AspectJ?

A: Aspects apply to everything in a namespace, as if everything is compiled together. Sometimes you can break the build down into separate steps without breaking this model, but we haven’t stated exactly where it could break because it depends on the interactions between all types. You can try the approaches below, but remember to rebuild everything in one go if there are problems.

The simplest scenario is when the aspects apply to all modules and the modules compile without the aspects. In that case, weaving in the aspects is just the final assembly step for the build.

Next is the case where the aspects make changes to a common library that are visible to other clients, which themselves are otherwise unaffected by the aspects. In this case, the common library can be built using ajc, and used on the classpath for the module builds:

Combining these last two, there’s the case where a common set of aspects should affect two or more modules that are in a dependency relationship to one another. It should work to reuse the aspects in binary form for each compile, in dependency order:

If two modules are visibly affected by aspects and mutually-dependent, the only thing to do is compile them together.

It’s safest to assume that all aspects can affect all types in a namespace; using build boundaries to effect crosscutting limits causes a dangerous dependency on the build process and might cause problems.

Q: We use modules and would like to use incremental compilation. Is that possible?

A: Just incrementally-compile the whole system. Specify to ajc the modules as multiple source roots (or input jars if you are weaving libraries).

In Eclipse’s AJDT, you can create a top-level project with symbolic links out to the sources:

Then everything is part of one huge incremental compile. Also, you can close this master project and work the others using the Java compiler or AJDT.

The links make incremental development possible without affecting the modularized Ant builds. (Our practice runs along those lines.)

Q: Is it possible to change methods by introducing keywords (like synchronized), adding parameters, or changing the "throws" clause?

A: 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 (no longer available) on the AspectJ users list, with some additional comments (no longer available) .

Q: I don’t understand what join points exist. How can I see them?

A: You can trace them using using an aspect. For example, you can start logging at a particular method call and see what join points occur after the call and before it returns.

Here’s some code Jim Hugunin wrote to trace join points and posted to the users list. To reuse the aspect, define a subaspect and implement the pointcuts, for example:

Here’s the aspect:

Note that if you are using AspectJ 1.0, the line starting with declare precedence would be removed, and the aspect declaration would look like aspect TraceMyJoinPoints dominates *.

Q: What is the difference between call and execution join points?

A: Briefly, 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 target 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.

Here’s more detail:

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 see #q:seeingjoinpoints[Q:I don’t understand what join points exist. How can I see them?].

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.

Because of differences in the way AspectJ 1.0 and 1.1 are implemented, in 1.0 you should use the call() pointcut designator unless you have a good reason to use execution(); in AspectJ 1.1, the reverse is true.

Q: What is the difference between cflow and cflowbelow?

A: 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.

Q: How do I say that I want the topmost entrypoint in a recursive call? How about the most-recent prior entrypoint?

A: 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:

Q: What is the difference between constructor call, constructor execution, initialization, and static initialization join points?

A: 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 from #q:seeingjoinpoints[Q:I don’t understand what join points exist. How can I see them?].

For a program compiled with AspectJ 1.0, the result is this:

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.

Q: How do I work with an object right when it is created?

A: You can advise some form of constructor join point. Constructors are tricky in Java, and that’s exposed in AspectJ. Here are some rules of thumb:

Q: I want advice to run at two join points, but it doesn’t run at all. What gives?

A: This usually reflects both a conceptual error and a programming mistake. Most likely you want to do something like "run the advice for all public and private calls," and the code looks something like this:

But a pointcut is evaluated at each join point. The expression above would never pick out any call join point, because no method signature has both public and private access. In a pointcut, pc1() && pc2() means both must be true at a given join point for advice to run at that join point. The correct pointcut would use || as follows:

Then the advice will run at the join point.

Q: How do I refer to a static field when my advice crosscuts multiple classes?

A: 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.

However, AspectJ can determine the class for something in the join point context, which you can use as a per-class key. Then you can actually declare an instance field to contain the per-class value (see the next question). This comes at the cost of an extra reference, but the field can be final.

Q: I would like to reuse a type pattern, e.g., to write advice that is limited to a certain set of classes. Do I have to retype it each time?

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

Q: Where do I find example programs and how-to’s?

A: There are a number of places to find sample code and instructions for using AspectJ with other programming tools.

This code can vary in quality. Code that we publish or include with AspectJ is generally correct. However, code found in our CVS tree might not have been tested thoroughly, and code from the mailing lists might be untested or use older versions of the language.

Q: Are aspect libraries available?

A: Some libraries are distributed in the release under the examples folder in the distribution. These are "libraries" in the sense that they are reusable, but they are delivered in source form. Similarly, some of the sample code is reusable; for that, see #q:exampleprograms[Q:Where do I find example programs and how-to’s?]. If you develop such a library and want to make it available to other users, feel to send it to the users mailing list aspectj-users@eclipse.org.

In AspectJ 1.1, ajc supports binary aspects, so you can distribute aspect libraries without distributing the source. For more information, see the -aspectpath option in the Reference for ajc.

Q: How does ajc interact with the serialVersionUID?

A: 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 Long-Term Persistence for JavaBeans Specification .

Q: How can I use AspectJ with applets?

A: Just include the aspectjrt.jar as a required archive. For example, here is the HTML code for an HTML editor applet that contains some debugging aspects:

The above markup has worked reliably with the Java Plugin (included in the JRE 1.4.x) in IE 6, Mozilla 1.1 (Win32), and Mozilla 1.0.1 (Red Hat Linux 8.0). The following link describes how to configure Mozilla/Netscape 6.x/7.x to use the Java Plugin from a JRE/SDK installation: https://java.sun.com/j2se/1.4.1/manual_install_linux.html. (Thanks to Chris Bartling for this answer.)

Q: How can I specify types for advice that captures primitives, void, etc.?

A: In some cases, AspectJ allows conversion from values of primitive types to Object, so that highly polymorphic advice may be written. This works if an advice parameter or the return type for around is typed to Object. So:

will print out

For more information, see the Programming Guide semantics section "Context Exposure" .

Q: How do I detect which version I am running?

A: The ajc compiler emits the version when passed the -version flag as an argument.

To programmatically detect the version of the AspectJ runtime while running under Java 1.4 or later, get the version from the package:

When running under Java 1.3 or earlier, read the manifest directly. For example code, see the source for AjBuildManager.checkRtJar(AjBuildConfig) in the org.aspectj.ajdt.internal.core.builder package of the org.aspectj.ajdt.core module, available as described in Q:How do I get and compile the source code for AspectJ?.

Note that the version of AspectJ for the tools in aspectjtools.jar is in org.aspectj.bridge.Version.

Q: How do I write synchronized advice?

A: The only modifier advice can take is strictfp. However, you can enclose the body of the advice in a synchronized clause:

It should not be necessary to synchronize a percflow aspect, but you might do this for perthis, pertarget, or issingleton (default) aspects. To serialize advice in multiple aspects, synchronize on a lock object available (only) to the aspects.

Q: When I run, I get a StackOverflowError (or a long stack trace or no output whatsoever)

A: 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:

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:

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:

In AspectJ 1.1, the String concatenation operator (+) is advised in its StringBuffer form, so if your advise uses String + in a way that is picked out by your pointcut, you will get infinite recursion.

(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:

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.

Q: I’ve declared a field on every class in my package; how do I use it in advice?

A: 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.

Q: The AspectJ compiler aborts with an OutOfMemoryError when compiling many classes. How can I fix this?

A: ajc can use more memory than a javac compile of the corresponding pure-java sources when aspects are added to the mix. You’ll need to increase the memory available.

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.

When running under Ant, give Ant more memory or use the fork option together with the Xmaxmem option.

When running under an IDE, look to the documentation for the IDE to determine how to increase available memory.

In either case, doing incremental compilations can hold on to more memory than a one-shot compile process, as the compiler trades space for time in recompiles.

Q: Why do I get a message that my class is already defined?

A: Most commonly, a source file was specified twice on the command line (e.g., directly and by a *.java entry in a .lst file). However, sometimes you have defined a class in two files in the same package, and you need to rename the class or change its scope. You should get this message from any Java compiler.

Q: ajc recompiles all files every time. How can I make it recompile only the files that have changed?

A: ajc 1.0 does not support incremental compilation, but since 1.1 ajc does when passed the -incremental option. It may still recompile files that have not changed, if they could be affected by aspects in particular ways, but the files compiled should be fewer and result in faster compiles. Further, the 1.1 release supports binary weaving, so you need not recompile if you already have .class files.

Q: ajc is using the wrong JVM. How do I fix it?

A: 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.

Q: My IDE is trying to parse AspectJ files which makes my project unusable. What can I do?

A: 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 and possible viewing crosscutting structure.)

Q: I used to be able to compile my program in my IDE, but when I use AJDE, I run out of memory (or it goes really slow).

A: The ajc compiler does more analysis than (e.g.,) javac, and AJDE may in some IDE’s hold a copy of the structure tree until the next tree is available from the compile process. Both mean that you may need extra memory to compile the same program. However, increasing available memory to the point that you are swapping to disk can slow the process considerably.

If you are having problems and would like to find the optimal memory allocation, iteratively decrease the amount of memory available until AJDE or ajc signals out-of-memory errors, and then increase that amount by 5-10%.

To increase memory for the ajc compiler, see #q:ajcoom[Q:The AspectJ compiler aborts with an OutOfMemoryError when compiling many classes. How can I fix this?]. For your IDE, do something similar or follow the provider’s instructions. For example, to increase memory, add something like this to your IDE’s config file or start script:

If it turns out that your project is too big to use with AJDE, your IDE may nonetheless support external commands or Ant build processes, which run outside the IDE memory space. For a JBuilder Ant plugin, some people have directed us to https://antrunner.sourceforge.net.

Q: When I run, I get a NoAspectBoundException or a ClassNotFound message for NoAspectBoundException.

A: This happens when an aspect is not associated with an object that is being advised. We have seen this happen two ways:

Q: My stack traces don’t make sense. What gives?

A: In 1.0, 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 Reference for ajc.

In 1.1, line numbers should work correctly. The only difference from a normal stack might be the addition of extra stack frames for call-backs.

Q: My advice is not running (or running twice), and I don’t know why.

A: When advice is not running, there 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, and your pointcut is staticly-determinable, use a declare statement to identify affected code. (For more information, see #q:knowWhenAspectsAffectClasses[Q: How do I know which aspects affect a class when looking at that class’s source code?].) If that does not work and your pointcut is dynamically determined, see if your join points are executing at all by using TraceJoinPoints.java from #q:seeingjoinpoints[Q:I don’t understand what join points exist. How can I see them?].

When advice is running more than it should, either (1) your advice is in an abstract aspect and the pointcut picks out the same join point for more than one concrete instantiation of the aspect, or (2) your pointcut picks out more join points than you intend.

In the case of advice in abstract aspects, the advice will run once for each concrete instance of the aspect. If the pointcut for that advice picks out the same join point for two concrete aspects, then the correct behavior is for the advice to run the advice twice at that join point.

To see if your pointcut picks out the join points you intend, you can use IDE support, logging, or declare-warnings. 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. Without IDE support, you can write declare-warning statements to identify code affected by staticly- determinable pointcuts. To identify advised dynamic join points, you can try using TraceJoinPoints.java as above, or update the advice to print the source location of the join point. Doing any of these should show if the advice applies to code that you did not expect.

If you’ve done this and convinced yourself it’s not working, it may be a bug. See #q:bugreports[Q:How do I submit a bug report?].

Q: My advice runs for each overridden method!

A: Most likely you are advising the method execution join point and specifying the defining signature. Since all overriding methods share this signature, the advice runs for each method executed. (This happens, e.g., when one method invokes the same method in the superclass using super.{method}(..)). This is the correct behavior.

To avoid this, use the call(..) pointcut designator, or use !cflow(..) to pick out only the initial method-execution.

Q: I don’t understand when thisEnclosingJoinPointStaticPart is available.

A: thisEnclosingJoinPointStaticPart is a special variable available in the context of advice to refer to the join point, if any, lexically enclosing the current join point:

Expressions in the body of handlers have the same thisEnclosingJoinPointStaticPart as the handler itself.

Q: I declared a member on a class with package access, but other classes in the package cannot see it.

A: When declaring parents on other types from an aspect, package access only applies to code the implementation controls. For AspectJ 1.0, that is the set of files passed to the compiler. That means other classes not compiled with the aspect will not be able to access the aspect-declared members even if they are in the same package. The only way for classes outside the control of the implementation to access aspect-declared members is to declare them public.

Q: I declared a member on a interface, but javac does not see it.

A: You have to compile all the top-level implementating classes of the interface using ajc. From an email by Jim Hugunin on the requirements for AspectJ 1.1 to implement members declared by an aspect on an interface:

If you introduce non-static fields or non-abstract methods on an interface from an aspect, then all of the top-most implementors of that interface must be woven by that same aspect. (A class C is a top-most implementor of an interface I if C implements I and the superclass of C does not implement I.)

Q: ajc 1.0 complains that it can’t find javac. What’s wrong?

A: ajc 1.0 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.

Q: I’m running under 1.4, but ajdoc asks for 1.3 (or throws IllegalAccessError for HtmlWriter.configuration)

A: The 1.0 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.

When running from the command-line scripts, edit the scripts directly to put the 1.3 tools.jar first on the classpath. (The installer does not know about this limitation of ajdoc.)

When running from Ant, users often have tools.jar in $\{ant.classpath} (to make javac, et al work). That makes it impossible to run the ajdoc taskdef (which does not currently support forking), so you’ll need to run a separate ant process, either from the command-line or via Ant’s exec task (the Ant task will propagate the classpath). If the wrong tools.jar is not on the ant classpath, then it should work to put the 1.3 tools.jar in the taskdef classpath.

Q: I set up different files to my compiles to change what the aspects see, but now I don’t understand how the aspects are working.

A: 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.

Q: I’m reading the code generated by ajc 1.0 in -preprocess mode, and it seems like it would not work (or "like it works this way").

A: 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.

Q: I’ve heard AspectJ can generate or inject code into my code. Is this true?

A: 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.

Q: Why can’t AspectJ pick out local variables (or array elements or …​)?

A: Users have sometimes wanted AspectJ to pick out many more join points, including

Most of these have turned out not to make sense, for a variety of reasons:

We prefer to be very conservative in the join point model for the language, so a new join point would have to be useful, sensible, and implementable. The most promising of the new join points proposed are for exception throws clauses and for synchronized blocks.

Q: Why doesn’t AspectJ pick out reflective calls? The pointcut call(void run()) won’t pick out a call using reflection, like ((Method)run).invoke(null, args).

A: The pointcut execution(void run()) will work. The call pointcut doesn’t work because Method.invoke(..) is the Java method-call, and AspectJ cannot delve into the Java reflection library to implement call semantics. To advise a reflective call (e.g., because the compiler does not control the code for the method execution), test the context for invoke(..). Here’s a pointcut that tests only if the method name is correct:

Q: What are the bugs now most affecting users?

A: The bugs affecting the semantics of the language are marked with the "info" keyword. Find them with the query https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&keywords=info

Q: What extra memory is required at runtime?

A: When running classes produced by the AspectJ weaver or compiler, there are no significant hidden uses of memory. As would be expected, each aspect is instantiated. The per-object aspects (like pertarget or perthis) in some implementations use a map to link aspects and the associated object. When using cflow-related pointcuts, a ThreadLocal is used to track control flow for each affected thread.

Of course, the size and code in an aspect can require memory. Aside from normal Java practices, take care with join point references. When referencing the static part of a join point (e.g., thisJoinPointStaticPart), only one object is created. However, if you reference the join point itself (e.g., thisJoinPoint), then one JoinPoint object will be created for each join point running advice.

Aspect instances will be garbage collected just like regular objects after there are no more strong references to them. For the default aspect instantiation model, issingleton, the aspect class retains a reference to the singleton instance, in order to implement static {AspectClass} aspectOf(), so singleton instances will not be garbage collected until the class is. For long-running or memory-critical programs, consider using weak references in singleton aspects for state that should be garbage collected.

Finally, when using load-time weaving, the weaver can require memory in its own right. Because the class loader never can know when it is done loading classes, the weaver can hold on to the aspects required to weave for some time. There are strategies for minimizing this (with different trade-off’s), so the time and memory required for load-time weaving will vary as load-time weaving evolves.

Q: I get a VerifyError when running CGLIB generated code that has been woven by AspectJ. Why is this?

A: When weaving after advice into any piece of code, the AspectJ strategy is to make all exit points from that code jump to a single exit point that executes the advice before returning. There is a verifier rule in the JVM specification that specifies that all routes to a jump destination must have the same height stack when they get there, regardless of the route taken to get there through the bytecode. The CGLIB generated code has different stack heights at the various exit points. This is not a problem with the CGLIB generated code, it is perfectly valid - it is just unusual and the AspectJ weaving strategy causes the verify error to trigger when it makes all exits jump to a single destination.

AspectJ could cope with this and instead implement after advice by calling the advice and returning at each exit point. However, it is unlikely that the user actually meant to weave the CGLIB generated code in the first place - and so usually the right thing to do is to exclude CGLIB generate code from the weaving process by appropriate use of the exclude element in the aop.xml. A typical clause in the aop.xml might look as follows:

Q: Why did the AspectJ project move to eclipse.org?

A: From the message sent to users:

AspectJ has come a long way — the language has stabilized; there are a rapidly growing number of commercial users; the 1.1 release is imminent and will include byte-code weaving and incremental compilation; and the tool support is now well integrated with several major IDEs.

This growth of the community and the technology means that the original research and prototype development of AspectJ is complete. As such it is time for ongoing development and support of AspectJ to move outside of PARC. This has already started to happen; the Eclipse AJDT plug-in and the several books in preparation are examples.

To encourage the growth of the AspectJ technology and community, PARC is transferring AspectJ to an openly-developed eclipse.org project. This project will include documentation, web site, mailing lists, bug database, and sources for the compiler. The command-line AspectJ compiler is still the primary tool produced by this project, in addition to APIs that support integration with a variety of IDEs. The Eclipse plug-in will remain at eclipse.org, while the NetBeans, JBuilder and Emacs support will move to SourceForge.net projects. We look forward to your involvement with and contribution to those projects.

We see Eclipse as an excellent new home for core AspectJ technology development — it is an active community of Open Source development and innovation in the Java space. Once development moves to Eclipse.org, others will be able to contribute more easily.

Q: Do I have to download Eclipse to use AspectJ?

A: No. The AspectJ tools download is completely self-contained and does not require that you work in Eclipse. For information on IDE support, see #q:integrateWithDevTools[Q: How well does AspectJ integrate with existing Java development tools?].

Q: What are the relationships between AspectJ, JDT, Eclipse, AJDT, and IDE support generally?

A: Eclipse is a software platform.

JDT is an eclipse project to support Java development. JDT has a Java compiler.

AspectJ 1.1 is built on Eclipse/JDT’s Java compiler but is distributed standalone and can run standalone. With the AspectJ distribution, you can compile and run AspectJ programs and use the AspectJ structure browser.

AJDT is an eclipse project to integrate AspectJ into Eclipse/JDT so you can use Eclipse to develop AspectJ programs. AJDT aims to support the full Eclipse experience - searching, compiler-error tasks, etc. AJDT will use the AspectJ Development Environment (AJDE) API’s for creating IDE integrations, as well as hooking in to the model underlying the Java compiler.

Similarly, Sourceforge has projects integrating AspectJ into other development environments using the AJDE API’s: AspectJ for Emacs, AspectJ for JBuilder, and AspectJ for NetBeans.

This is the right level of separation/integration. AspectJ is available standalone, leverages an existing open-source compliant Java compiler, and supports external projects doing IDE integrations in Eclipse, Emacs, JBuilder, and NetBeans through a common API, AJDE.

Q: What are the new features of AspectJ 5?

A: All the new features are documented in the AspectJ 5 Developer’s Notebook and the AspectJ Development Environment Guide. To summarize:

Q: Should I use code- or annotation-style aspects?

A: To use AspectJ, you can use the original code-style aspects or the annotation-style aspects new in AspectJ 5.

The original code-style is a small extension of the Java language designed to express crosscutting as clearly as possible in ways familiar to most Java programmers. To use the original code-style aspects, compile them with the AspectJ compiler or weave pre-compiled binary aspects using the AspectJ binary (.class) weaver, either at build-time or at class-load-time. Code-style aspects have excellent IDE support, allowing you to navigate to and from affected source code.

Annotation-style aspects are written (not surprisingly) using annotations. They use the subset of the AspectJ language that works when aspects are woven after the code is compiled. The source files are compiled with Javac, which simply saves the annotations in the .class files. The resulting .class files must be woven using the AspectJ weaver, which reads the annotations from the .class file and uses them to define aspects. Annotation-style aspects have the benefit of being compilable by Javac, but you can’t use the full AspectJ language, and you don’t enjoy the same level of IDE support for viewing crosscutting structure.

Q: What’s new about the load-time weaving support in AspectJ 5?

A: While the AspectJ weaver could be used at load-time in previous releases, the AspectJ 5 release supports much better integration with the Java 5 VM and the BEA JRocket JVM. It also supports an XML file for configuration that allows deployers to declare concrete aspects using only XML. This means aspect developers can write abstract aspects, and deployers need only configure aop.xml and run using the AspectJ weaver in Java 5. For example, to run Java 5 VM with load-time weaving,

To declare a concrete aspect, add a a concrete-aspect XML entity to META-INF/aop.xml. This example extends a tracing aspect to apply to every type in the application:

For more information, see the AspectJ Development Environment Guide.

Q: Do I need to know how the compiler or weaver works?

A: Writing AspectJ programs only requires understanding the Programming Guide. However, current implementations do not control everything in a system, so AspectJ program semantics may be limited to code the implementation controls. For our implementation, these limitations are stated in Programming Guide Appendix: Implementation Notes. Aside from understanding the use and limitations of the implementation, there is no need to understand the underlying technology when writing AspectJ programs.

The technology that implements AspectJ interests some academic researchers and some developers who want new features or new ways to weave. These extensions are not discussed in the documentation. Some are being developed already, others are on the drawing board (or perhaps were left off long ago), and still others haven’t been considered. If you are interested in a certain extension, check the bug database for feature requests and the mailing list archives for any past discussions. Then email the list to see if it’s been considered. For more information, see AspectJ Project Development.

Q: How does the compiler/weaver work? Are there any white papers?

A: There are currently no documents describing this process in detail. You can compile programs and inspect the generated source or bytecode, or view the source code (see AspectJ Project Development). We hope to write papers on the bytecode weaving model used in AspectJ-1.1 if we can find the time. Erik Hilsdale and Jim Hugunin did draft a paper for AOSD 2004, now available on Jim’s web site: https://hugunin.net/papers.html Jim summarized advice weaving in the AspectJ 1.1 implementation in the following mailing-list reply:

Each piece of advice in an aspect is associated with a pointcut. This pointcut is stored in an attribute on the methods corresponding to each piece of advice. Before weaving, all of these pieces of advice are gathered into one large list.

Each .class file is woven independently. A .class file is woven by the following steps:

See BcelClassWeaver and BcelShadow in the org.aspectj.weaver.bcel package for the two primary classes involved in this process.

Note: This explanation ignores the implementations of inter-type declarations completely. It also ignores performance optimizations such as fast-match or pipelining that speed up the process.

Q: How do I get load-time weaving to work in my chosen application server?

A: You have two choices based on how wide you want the weaving to take effect: application-server wide and application-specific weaving. You choose between the two by loading aspect artifacts—​aspects, associated types, and aop.xml—​through the right classloader. The aop.xml must be in the META-INF directory on the classpath for the chosen classloader. In either case, you modify the startup script to specify the -javaagent:path-to/aspectjweaver.jar option to the Java virtual machine. Note that it is not essential that all the artifacts be placed in a single jar.

For application-server wide weaving, you make aspect artifacts accessible to the server’s classloader. Typically, you achieve such access by putting these artifacts in the server’s lib directory. For example, for Tomcat, you will place the aspect artifacts in the TOMCAT_HOME/lib directory.

For application-specific weaving, you make aspect artifacts accessible to application classloader by bundling them along with application’s classes. For example, for a web application, you will place the aspect artifacts in the MY_APP/WEB-INF/lib and/or MY_APP/WEB-INF/classes directory.

We recommend that you start with application-specific weaving. Note that you have an additional option if your application is based on the Spring framework. If you deploy in one of the supported web servers or application servers, you can avoid modifications to the startup script. Please see https://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw-spring for more details.

Q: Does AspectJ use reflection at runtime?

A: The only time that reflection is used during run-time is when the special thisJoinPoint object is used to discover reflective information about the join point. If you don’t use thisJoinPoint then no reflection will be used.

Q: What about load-time weaving? Can I weave aspects at runtime?

A: Since the 1.1 release, AspectJ can weave binary aspects into classes in bytecode form. Hooked up to a class loader, this can weave class bytecodes after they are read in, before the class is defined by the VM. (This means load-time weaving only works were aspects are not required to compile the pure-java classes. If the aspects are required, then the Java classes have to be compiled with the aspects using the AspectJ compiler.) The AspectJ 1.2 release had the WeavingURLClassLoader, and the 1.2.1 release introduced the aj.bat script for Java 1.4. The AspectJ 5 release introduces much better support for load-time weaving, including declaring concrete aspects in XML files and integrating with Java 5 and BEA JRocket JVM’s. See #q:aspectj5ltw[Q:What’s new about the load-time weaving support in AspectJ 5?].

Some have asked about only weaving particular classes specified at run-time. Aspects should work across an entire namespace, and problems will likely result from weaving some classes but not others. Also, it’s confusing to specify crosscutting both in the aspect and in the list of runtime classes; the crosscutting specification should be in the aspect itself, where it can be processed by tools.

And just to state the obvious: do not use bytecode weaving, at load-time or otherwise, to modify .class files protected by license, without permission from the licensor.

Q: I’m interested in the code implementing AspectJ.

A: Most people do not need to see the code for AspectJ; they can download the binary distribution for documentation and tools for writing AspectJ programs.

For people who want to know how the AspectJ technology works, the source code is the best resource, until we write some proper white papers (see #q:implementation[Q:Do I need to know how the compiler works?]). To get and compile the Java source code for the AspectJ distribution, see Q:How do I get and compile the source code for AspectJ?.

Bear in mind when looking at the code that there are many ways to implement the AspectJ language, and the code inspected might be an initial version of a new architecture (e.g., bytecode weaving).

Q: How can I get involved with developing the AspectJ project?

A: For those who want to contribute to the project, here’s a general list of ways to do so, in no particular order:

Q: How do I get and compile the source code for AspectJ?

A: The AspectJ source code is available on the AspectJ GitHub page. Read-me section Building briefly explains how to compile AspectJ from scratch. Read-me section Documentation for AspectJ developers links to more detailed resources about build options, how to contribute to the project and how to release it.

For the latest AspectJ Development Tools (AJDT) for Eclipse release, please visit the AJDT Downloads page.

Q: How do I build AspectJ and integrate it into AJDT?

A: [TODO: outdated, update!] To build AspectJ, first get the source tree as described in Q:How do I get and compile the source code for AspectJ?. Once you have a development environment set up, copy the build/sample-local.properties file to build/local.properties and within this file point the java14.home and java15.home to the corresponding places on your machine.

To build AspectJ on the command line:

To import a locally built AspectJ into AJDT first follow the instructions on How do I setup an AJDT development environment in Eclipse? for setting up an AJDT development environment and running the correctness tests. Then:

Q: Where do I find developer documentation on building and testing AspectJ source code?

A: Find the developer documentation in HTML files in the CVS tree, inside the build and testing modules (i.e., in org.aspectj/modules/build/…​). Most pertinant:

Q: How should I submit test cases for bugs?

A: You can attach files to a bug after it has been created. The code of course should replicate the actual behavior described in the bug when run on the target version. If you have a single source file, you can attach it directly, describing in the comments the expected result (e.g., error on line 14, or successful compile/run). The most helpful form for describing the test scenario and the expected results are the test definitions described next.

For more complex bugs requiring many files, create a zip file of a directory containing all the files and an XML test definition file. The XML test definition file contains specifications for how to compile, recompile, or run the test sources. Complete documentation is available in the CVS tree at tests/readme-writing-compiler-tests.html but here is a sample file with some example definitions, preceded by comments showing the directory layout of the files referred to in the test definitions.

Q: I’d like to run my test case. How do I get the test harness?

A: The test harness is not distributed. To build it, get the source tree as described in Q:How do I get and compile the source code for AspectJ? and then build the build-testing-drivers target:

This produces ../aj-build/jars/testing-drivers-all.jar which you can run as described in tests/readme-tests-module.html.

Q: BCEL is used by AspectJ but it’s not actively developed. Will you change?

A: The AspectJ bytecode weaver has used BCEL for bytecode manipulation since its first release. We have upgraded it extensively, to improve performance, support Java 5, etc. The BCEL developers have not incorporated our patches, so we continue to maintain our own version. Ours has been optimized for the AspectJ weaver and battle-hardened over years of development and use. At some point in the future, the AspectJ weaver might be restructured to make it easy to see whether another bytecode package offers the same stability, functionality, and performance, but for now we prefer using something that we know works well.

In the AspectJ 5 release, the weaver has been restructured to use reflection where possible. Otherwise, it continues to use BCEL, but does not hold BCEL structures in memory after our evaluation completes.

Q: How do I find out more about AspectJ?

A: Visit the AspectJ project web site: https://eclipse.org/aspectj.

Q: How do I submit a bug report?

A: You can submit a bug from https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ . If it seems to be a bug in the compiler, please attach a small test case (source code) to reproduce the problem. For more information on writing compiler test cases, see #q:ajcbugs[Q:How do I write bugs for the AspectJ compiler?]. If you are unable to submit a test case, consider submitting traces, ajcore files, and/or .class dump files, as described in the AspectJ Problem Diagnosis Guide.

Q: How do I communicate with other AspectJ users?

A: You can reach other AspectJ users by using the aspectj-users mailing list. You can subscribe to the list or view the list archives from the AspectJ home page https://eclipse.org/aspectj .

Q: How can I search the email archives or the web site?

A: It is very effective to do a google search of the form, https://www.google.com/search?q=site:eclipse.org+cflowbelow , and you can use the eclipse.org search at https://www.eclipse.org/search/search.cgi . You can also check the old archives available for download from the AspectJ home page https://eclipse.org/aspectj .

Q: How should I write email queries?

A: Here’s the general form of a good email:

The big picture helps others redirect you to other approaches. Using AspectJ terms helps others correct mistakes in thinking about the problem (the most common being to confuse join points and pointcuts). 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. The code should not be incomplete; it should run (or fail) as-is, without additional libraries or source files.

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 https://jakarta.apache.org/site/mail.html and https://www.tuxedo.org/%7Eesr/faqs/smart-questions.html .

Q: How do I write bugs for IDE support?

A: Bugs appearing in the IDE’s may apply to the affected IDE or to the compiler. Compiler stack traces in IDE message windows are prefixed "Internal Compiler Error" and should be written up as compiler bugs. If you are unsure, try redoing the compile from the command line.

Bug report for the IDE extensions go to their respective projects, listed in #q:integrateWithDevTools[Q: How well does AspectJ integrate with existing Java development tools?] (including bug reports for the AJDE Eclipse support, which you can submit at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AJDT ).

One of the benefits of open-source is that you can find and fix the bug for yourself; when you submit the fix back to us, we can validate the fix for you and incorporate it into the next release. You can submit a patch by attaching it to the bug.

Q: How do I write bugs for the AspectJ compiler?

A: The best compiler bug report is a reproducible test case, standalone code that demonstrates the problem. Sometimes with aspects, a test case requires several files, if not some way to capture the behavior. Here’s how we recommend submitting test cases:

Q: Can you recommend reading or teaching material for AspectJ?

A: The documentation available in the distribution is the best source for language and usage questions.

Q: Where can our group get consulting and support?

A: The best thing to do is join and email the aspectj-dev@eclipse.org mailing list.

Q: What has changed since the last FAQ version?

A: Entries changed recently:

Q: What does the fact that AspectJ is an Open Source Project mean to me?

A: Open source protects your interest in a correct, long-lived, up-to-date, and widely-accepted implementation of AspectJ.

Q: What are your plans to make AspectJ a general feature of Java supported by Sun and the other key players in the Java Industry?

A: 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 developing for the 1.1 implementation which improves AspectJ in key areas: rapid incremental compilation, bytecode weaving, and IDE integration.

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 in good position to explore the best path for AspectJ in the long term.

Q: When will AspectJ work from class files? When will it work at class-loading time?

A: Bytecode weaving is in AspectJ 1.1. We believe it works as described in 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.

…​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. We expect to have a demonstration classloader available in the 1.1 release or soon thereafter.

Q: What are the differences between the current and previously released versions of AspectJ?

A: The AspectJ team aims to keep the implementation bug-free and up-to-date with the Java language, to limit AspectJ language changes to those that are carefully considered, compelling, and backwards-compatible, and to deliver those language changes only in significant releases (1.0, 1.1).

More details for 1.0 and earlier releases are available in changes.html.

Q: What is the AspectJ development schedule?

A: Below is a table describing the goals for the major releases. For information about specific features, search the bug database for RFE's ("requests for enhancement") by selecting severity of "enhancement". Like many open-source projects, we don’t make or promise schedules, but we do follow a pattern of issuing preview releases which can give observers an idea of when a particular release might be available.

Q: Will AspectJ support Java 5?

A: Yes. Java 5 is supported in AspectJ 5.

AspectJ is a registered trademark of Palo Alto Research Center, Incorporated (PARC), used with permission. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All other trademarks are the property of their respective owners.