© Copyright 1997-2001 Xerox Corporation. All rights reserved.
Last updated for AspectJ 1.0rc1
AspectJ is a simple and practical extension to the Java 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 are concerns that affect more than one class.
AspectJ includes a compiler (ajc), a debugger (ajdb), a documentation generator (ajdoc), and integration with JBuilder, Forte and GNU Emacs/XEmacs.
AspectJ can be used to improve the modularity of software systems.
Using ordinary Java, it can be difficult to modularize design concerns such as
The code for these concerns tends to be spread out across the system. Because these concerns won't stay inside of any one module boundary, we say that they crosscut the system's modularity.
AspectJ adds constructs to Java that enable the modular implementation of crosscutting concerns. This ability is particularly valuable because crosscutting concerns tend to be both complex and poorly localized, making them hard to deal with.
AspectJ is an evolving aspect-oriented extension to Java. It is based on over ten years of research at Xerox Palo Alto Research Center, funded by Xerox, a U.S. Government grant (NISTATP), and a DARPA contract.
Current development of the system is focused on stabilizing the language, improving compiler performance and integration with IDEs and other code development tools like javadoc. This development is being guided by feedback from the AspectJ user community.
The latest release is 1.0rc1 which can be downloaded from the AspectJ download page.
AspectJ has been designed as a compatible extension to Java. By compatible, we mean
| upward compatible | All legal Java programs are legal AspectJ programs. |
| platform compatible | All legal AspectJ programs run on standard Java virtual machines. |
| tool compatible | Existing tools can be extended to work with AspectJ. |
| programmer compatible | Programming in AspectJ feels natural to Java programmers. |
The AspectJ tools run on any Java 2 Platform compatible platform.
There are many recent proposals for programming languages that provide control over crosscutting concerns. Aspect-oriented programming is an overall framework into which many of these approaches fit. AspectJ is one particular instance of AOP, distinguished by the fact that it was designed from the ground up to be compatible with Java.
See the Related Sites page of the AspectJ web site for more information.
Reflective and aspect-oriented languages have an important similarity: both provide programming support for dealing with crosscutting concerns. In this sense reflection was the existence proof that independent programming of crosscutting concerns is possible.
But the control that reflection provides tends to be low-level and extremely powerful. In contrast, AspectJ provides more carefully controlled power, drawing on the rules learned from object-oriented development to encourage a clean and understandable program structure.
Some features of AspectJ, such as introduction, are related to mixin-based inheritance. But, in order to support crosscutting, a core goal for AspectJ, AspectJ goes beyond mixin-based inheritance.
Firstly, an aspect imposes behavior on a class, rather than a class requesting behavior from an aspect. An aspect can modify a class without needing to edit that class. This property is sometimes called reverse inheritance.
Secondly, a single aspect can affect multiple classes in different ways. A single paint aspect can add different paint methods to all the classes that know how to paint, unlike mixin classes.
Finally, aspect instances support state crosscutting in a way that mixin-based inheritance cannot.
In order of increasing complexity, you may
In the development process Use AspectJ just to trace or log interesting information. You can do this by adding to any Java program simple AspectJ code that performs logging or tracing of objects. This kind of addition may be removed for the final build since it does not implement a design requirement; the functionality of the system is unaffected by the aspect.
As an ancillary part of your system Use AspectJ as a more involved testing harness. Add more sophisticated code that can help with either debugging or testing. This code may also usually be removed from the final build.
As an essential part of your system Use AspectJ to factor out some crosscutting concern in the core of your system. Add AspectJ code that implements some design requirement. This code cannot be removed from the final build.
This adoption sequence works very well in practice and has been followed by many users.
Simple development support is available through the support mailing list, and the AspectJ users mailing list provides an informal network of AspectJ experts. To subscribe to either list, visit the Mailing Lists page of the AspectJ web site.
Members of the AspectJ team are available to work with users in more depth on both program design and implementation issues. The team may also be able to provide speakers. Please contact the AspectJ team with your request.
The AspectJ releases consists of extensions to standard Java tools, the AspectJ Development Environment (AJDE), and documentation.
AspectJ provides replacements for standard Java tools:
The AspectJ Development Environment (AJDE) is integrated with or augments several common Java development environments. It brings to the aspect-oriented programmer the ability to navigate the aspect structure of their programs, just as object-oriented environments brought to object-oriented programmers the ability to navigate object relationships, i.e. the inheritance hierarchy.
The AspectJ Development Environment (AJDE) integrates with the following tools:
Support for other IDEs is not planned until after the 1.0 release. Our current efforts are focused on the stability, performance, and extensibility of the core AJDE support. The following IDEs are being considered for future support (mail us if you would like to add your IDE to this list or desire support for one of the IDEs listed below):
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:
AspectJ is an addition to Java, and can be added to a project in a way that limits risk. See Q: How do I start using AspectJ? for some suggestions on how to do this.
The AspectJ compiler accepts standard Java as input and produces standard Java bytecode as output. An optional mode produces standard Java 2 source code which may then be compiled with any compliant Java compiler, e.g. Sun's javac compiler or IBM's jikes compiler. The bytecode output will run on any standard Java 2 virtual machine.
AspectJ is available under the Mozilla Public License, a non-proprietary, open source license. This ensures that AspectJ will continue to evolve and be available, regardless of the fate of any particular organization involved with AspectJ.
Removing AspectJ from your program is not difficult, although you may lose valuable functionality that will need to be re-implemented in Java.
AspectJ is open-source software and is available under the Mozilla Public License. The documentation is available under a separate license that precludes for-profit or commercial redistribution.
You can submit a bug using the web interface (preferred), or you may send email to support@aspectj.org.
You can contact the AspectJ team to find out more about AspectJ, or you may visit the AspectJ website.
You can reach other AspectJ users by using the aspectj-users mailing list. To subscribe to the list or view the list archives go to the user community page.
The documentation available on this site is a primary source of material on AspectJ:
| Selected AspectJ Papers and Presentations | Papers presented at various conferences; tutorial slide presentations. |
| Aspect-Oriented Programming | The seminal AOP/AspectJ paper |
| The AspectJ Programming Guide | A practical guide for programmers. Includes a number of examples, some quite sophisticated. |
| The AspectJ Tutorial | Slides from a day-long tutorial presentation on AspectJ. |
Some libraries are distributed in the release under the examples folder in the distribution. If you develop a library and want to make it available to other users, make sure to contact us.
You can contact the AspectJ team to submit comments and feature requests.
Use the latest, greatest, fastest JVM you can get your hands on for your platform. The compiler's performance is dependent on the performance of the JVM it is running on, so the faster a JVM you can find to run it on, the shorter your compile times will be. At a minimum you need to use a Java 2 or later JVM to run the compiler. We realize that this constraint can be a problem for users who are running on Macintosh (until OS X in early 2001) and FreeBSD that don't currently have a Java 2 JVM available. We're sorry for the inconvenience, but we had to make the hard decision that the advantages of being able to rely on Java 2 were worth the cost of losing a number of developers who are working on platforms without Java 2 support. Here is a list of starting places where you might find support for your system.
The requirement of Java 2 support is only for running the AspectJ compiler. The AspectJ compiler can be used to build programs that will run on Java 1.1 (or probably even on Java 1.0) systems. This means that it can build programs that will run on Macintosh, FreeBSD, and applets that will run in Internet Explorer and Netscape Navigator that are still not yet Java 2 compliant.
ajc can be used to develop programs that are targeted at the Java 1.1 platform, even though the ajc compiler won't run on that platform. Here's an example of using ajc in this sort of cross-compilation mode (assuming a Windows platform with all the default installation directories):
ajc -target 1.1 -bootclasspath c:\jdk1.1.7\lib\classes.zip \ -classpath c:\aspectj0.7\lib\aspectjrt.jar \ -extdirs "" \ -arglist jdk11system.lst
This same technique can be used if you want to run ajc on a JDK 1.3 JVM (highly recommended) but need to generate code for JDK 1.2. That would look something like:
ajc -bootclasspath c:\jdk1.2\jre\lib\rt.jar \
-classpath c:\aspectj0.7\lib\aspectjrt.jar \
-extdirs c:\jdk1.2\jre\lib\ext -arglist jdk12system.lstWe have developed IDE support that gives programmers a clear and easy-to-use 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.
See Q: How well does AspectJ integrate with existing Java development tools? for more information on which Java development environments are supported.
8. 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?
Yes, you can use the @ feature. Create a file called, for example, project, the contents of which consists of one filename per line. So it might look like:
OneClass.java TwoClass.java page/AClass.java page/BClass.java page/body/ThisClass.java page/body/ThatClass.java
Then you can run the compiler as follows:
ajc @project
No. You need only to compile with AspectJ the files that contains your aspects and the files that contain the classes that are affected by your aspect. See Q: How do I know which aspects affect a class when looking at that class's source code?.
1. It looks like aspects break the manifest interface of a class since they can access and modify all data members. Why did you make that decision?
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.
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,
3. 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?
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.
The short summary is that it is right to define AOP in terms of crosscutting, because well-written AOP programs have clear crosscutting structure. It would be a mistake to define AOP in terms of "cleaning up tangling and scattering", because that isn't particular to AOP, and past programming language innovations also do that, as will future developments.
Slides for a long talk on this topic are at http://www.cs.ubc.ca/~gregor/vinst-2-17-01.zip.
At this time, unfortunately not. The two compilers are just not at all compatible. In an ideal world, there would be a wonderful Open Source extensible compiler framework for Java that both GJ and AspectJ would be built on top of, and they would seamlessly interoperate along with all other extensions to Java that you might be interested in, but that's not the case (yet?).
However, on 09 October 2000, the Java Community Process approved a proposal to add generic types to Java that is largely based on GJ (JSR 14). A draft specification was submitted for public review, which closed on 01 August 2001, and a prototype implementation has been released.
We are committed to moving very rapidly to add support for generic types in AspectJ when generic types become part of the Java language specification. Everyone on the AspectJ team is looking forward to this, because we too would really like to be able to write code that includes both aspects and generic types.
Using aspects reduces, as a side effect, the number of source lines in a program. However, the major benefit of using aspects comes from improving the modularity of a program, not because the program is smaller. Aspects gather into a module concerns that would otherwise be scattered across or duplicated in multiple classes.
The issue of performance overhead is an important one. It is also quite subtle, since knowing what to measure is at least as important as knowing how to measure it, and neither is always apparent.
There is currently no benchmark suite for AOP languages in general nor for AspectJ in particular. It is probably too early to develop such a suite because AspectJ needs more maturation of the language and the coding styles first. Coding styles really drive the development of the benchmark suites since they suggest what is important to measure.
In the absence of a benchmark suite, AspectJ probably has an acceptable performance for everything except non-static advice. Introductions and static advice should have extremely small performance overheads compared to the same functionality implemented by hand.
If you'd like to measure the performance be sure to write code fragments in AspectJ and compare them to the performance of the corresponding code written without AspectJ. For example, don't compare a method with before/after advice that grabs a lock to just the method. That would be comparing apples and oranges. Also be sure to watch out for JIT effects that come from empty method bodies and the like. Our experience is that they can be quite misleading in understanding what you've measured.
Go to AspectJ's download web page and choose which components you want download. The jar files are installed by executing
java -jar jar file nameDo not try to extract the jar file contents and then attempt to execute java org.aspectj.Main. (A NoClassDefFoundError exception will be thrown.) The AspectJ distribution is not designed to be installed this way. Use the java -jar form shown above.
The compressed tar files (suffix: .tgz) are extracted by decompressing them with tar or with WinZip.
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.
ajc does not try to locate javac in your path: it uses the javac classes directly. In JDK 1.2 and 1.3 these classes are found in tools.jar (in the lib directory of the JDK distribution), which you must include in your classpath in order to make ajc work with javac. You have to make sure that tools.jar is accessible on your classpath.
The uninstall process for AspectJ only requires you to remove the files that the installer wrote in your file system. Delete the top-level installation directory (and all the files beneath it) that you specified when you installed AspectJ. On Windows, no registry settings were added or changed, so nothing needs to be undone.
| Version | Description |
| AspectJ 1.0 | Many language changes, fixes, cleanup and clarifications, some significant. |
| AspectJ 0.8 | More cleanup of the syntax and semantics. |
| AspectJ 0.7 | Clean up of the semantics, 0.7 beta 4 is the first open source release. |
| AspectJ 0.6 | Advice and crosscuts get explicit type signatures which describe the values that are available to advice at a crosscut. |
| AspectJ 0.5 | Improved tool support: better Emacs environment support and ajdoc to parallel javadoc. around advice is added, and the aspect keyword is removed and replaced by the Java keyword class. |
| AspectJ 0.4 | Clear separation of crosscuts and crosscut actions makes it possible to define extensible library aspects. |
| AspectJ 0.3 | First all Java implementation, also includes many small language improvements. |
| AspectJ 0.2 | General-purpose support for crosscutting. Users could program any kind of aspects, not just coordination. This release dropped COOL. |
| AspectJ 0.1 | A single domain-specific aspect language, called COOL, for programming coordination in multi-threaded programs. |
More detailed comments are available in the doc/changes.html file in the distribution.
Join points are well-defined points in the execution of a program. Not every execution point is a join point: only those points that can be used in a disciplined and principled manner are. So, in AspectJ, the execution of a method call is a join point, but "the execution of the expression at line 37 in file Foo.java" is not.
The rationale for restricting join points is similar to the rationale for restricting access to memory (pointers) or restricting control flow expressions (goto) in Java: programs are easier to understand, maintain and extend without the full power of the feature.
AspectJ join points include reading or writing a field; calling or executing an exception handler, method or constructor.
A pointcut picks out join points. These joint points are described by the pointcut declaration. Pointcuts can be defined in classes or in aspects, and can be named or be anonymous.
Advice is code that executes at each in a join point picked out by a pointcut. There are three kinds of advice: before advice, around advice and after advice. As their names suggest, before advice runs before the join point executes; around advice executes before and after the join point; and after advice executes after the joint point. The power of advice comes from the advice being able to access values in the execution context of a pointcut.
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...
aspects can additionally include pointcuts; before, around and after advice; and introductions as members
aspects can be qualified by specifying the context in which the non-static state is available
aspects don't have constructors or finalizers, and they cannot be created with the new operator
privileged aspects can access private members of other types
It's not currently possible to introduce any keywords onto methods. However, for the case of synchronized in particular, we have what we consider a better solution that uses around advice instead of introduction. This solution is described in this thread on the AspectJ users list, with some additional comments.
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 .
There are two philosophies in the Open Source community about when to do the first Open Source release of a system. One philosophy says "release early and release often". The current AspectJ source code release is based on that philosophy. This approach has the wonderful property of offering no excuses for delaying a release until things are "just right" which can often mean never releasing the source code at all.
The other philosophy says that you shouldn't make an Open Source release until the sources are relatively clean, and the core design of the system is relatively stable. This approach makes it much easier for outside developers to make significant contributions to the project. We believe that clean sources and a stable design is an admirable goal for any software project, but we don't want to delay making an Open Source release of AspectJ until we reach that point.
Instead we're just going to include this warning:
AspectJ is a new kind of programming language, and our understanding of how best to design a compiler for it is rapidly evolving. We plan to continually improve and frequently redesign the compiler as our understanding of AOP improves. We expect that the class hierarchies, method names, and fundamental design of the whole system will be significantly changing on a monthly or even weekly basis. No effort whatsoever will be spent at this point in the project to make new versions of the compiler even vaguely resemble a previous release in terms of internal design (Note: we will spend considerable effort to ensure that the compiler will behave in a consistent fashion externally to users of previous versions).
We expect this period of rapid development to end at some point. We'll be sure to announce it very clearly when we think the basic internal structure of the compiler is relatively stable and we believe it would be a reasonable platform for outside developers to look at and contribute to. Until we make that announcement, well, you've been warned.
So, given that warning, what good is the Open Source release?
Knowing that the compiler for AspectJ will be Open Source when we get to version 1.0 is important. Building a significant system using a brand new emerging language is daring enough. Doing this without the knowledge that the source code is publicly available is too much to ask of many people. For this purpose, a promise to release AspectJ as Open Source as soon as we got to version 1.0 might be good enough; however, an actual release is always better than a promise.
If people want to help us fix bugs, we certainly won't object. This can be valuable to our users in allowing them to fix some of their own bugs immediately rather than waiting for us to make a new release. It can also be valuable to us if people choose to include bug fixes with their bug reports.
The code is out there. If you're doing a throw-away research project, then it might be useful even with our dire warnings about radical refactorings. If your project can afford to pick a single release of the source code to build on top of and not worry about keeping up with our bug fixes and improvements then the source code could be valuable to you even in its current rapidly changing state.
2. What are your plans to make AspectJ a general feature of Java supported by Sun and the other key-players in the Java Industry?
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.
Our current focus is on getting a high-quality 1.0 release out. That release will stabilize the language and will include increased tool support. Shortly following the 1.0 release we intend to improve the AspectJ compiler in two directions: support for rapid incremental compilation and efficiency. We will also be releasing AspectJ-specific support for several popular IDEs.
Through all of this our goal is to make AspectJ integrate as seamlessly as possible with the Java programming language. The AspectJ language design is becoming more integrated, the compiler is becoming faster and more integrated, the IDE extensions are becoming more integrated. All of this is designed to help users really use AspectJ and give us feedback on it.
As more of the system is improved, and we get more feedback from users, we will be better positioned to explore the best path for long-term AspectJ support.
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.