To navigate to the AspectWerkz documentation, please follow this link.
 
 

AspectJ and AspectWerkz to Join Forces

The AspectJ (1) and AspectWerkz (2) projects have agreed to work together as one team to produce a single aspect-oriented programming platform building on their complementary strengths and expertise. The first release from this collaboration will be AspectJ 5, which extends the AspectJ language to support an annotation-based development style in addition to the familiar AspectJ code-based style. AspectJ 5 will also provide full AOP support for the new Java(tm) 5 language features.

 A Natural Step...

The AspectWerkz language has been moving closer and closer to that of AspectJ. The key difference is that whereas AspectJ uses a syntax that complements Java as defined in the original JLS (Java Language Specification), AspectWerkz supports both annotation and XML based styles of development. In addition, AspectWerkz has focused largely on close integration of load-time weaving into J2EE application environments while AspectJ has focused more on (static) compilation and weaving, runtime performance, and tools support.

A complete AOP environment needs a strong conceptual model, first-class IDE support, a type-safe language, high performance, support for a variety of weaving times and deployment modes, an aspect library, and the ability to be easily integrated into existing application environments. Full integration with the new features of Java 5 is essential, including annotations, generics, auto-boxing, covariance, varargs, and enums.

The combined strengths of the two teams will enable us to deliver a more comprehensive technology suite more quickly than either team could alone. The backing of two major vendors (IBM and BEA) and a large open source community will accelerate the adoption of AOP in the enterprise. AspectJ 5 will continue as a fully open-source project on Eclipse.org.

Following the AspectWerkz 2.0 release, the AspectWerkz developers will be joining the AspectJ project to bring the key features of AspectWerkz to the AspectJ platform. This will begin with an extension to the AspectJ language to support an annotation-based style of development, and with tighter integration of load-time weaving for AspectJ in the J2EE environment. A smooth migration path for existing AspectWerkz users is a key priority in the development and release planning.

 Development Plans

We anticipate delivery of the first AspectJ 5 release in March 2005 (with milestone releases ahead of that date). This release will contain full support for the new features of Java 5, and support for an annotation-based development style in addition to the more familiar AspectJ code-based style. We informally call the set of annotations for the annotation style of development the "@AspectJ" annotations. See the work-in-progress AspectJ 5 Developer's Notebook (3) for details of these features. The AspectJ Development Tools (AJDT) for Eclipse will also be enhanced to provide support for the annotation style.

AspectJ 5 will also include an aspect library. Just as with the JDK, over time much of the value in the AspectJ 5 platform will come from these libraries, and they will provide an even faster way for new users to become productive working with AspectJ "straight out of the box".

The March release is just the first of several AspectJ 5 releases planned for 2005. Follow-on releases will deliver more of the load-time weaving features of AspectWerkz. As part of this work, we will also enable support for JRockit optimizations. Adding to the aspect libraries shipped with AspectJ 5, and reducing further the time and memory consumption of the weaver are also high-priority items.

 AspectJ 5

AspectJ 5 will have an even larger and more active user community formed from bringing together the existing AspectJ and AspectWerkz users. The existing AspectJ website and mailing lists will be used to support this community. The development team working on AspectJ 5 will also be larger than either of the current AspectJ and AspectWerkz teams, accelerating the rate of progress.

In AspectJ 5 the AspectJ language is extended to support both a code style and an annotation style of development. These provide equivalent ways to write AspectJ programs, and give the broadest support possible for the mix of development tools, IDEs, and processes used in development projects today. The Eclipse AspectJ Development Tools (AJDT) will work with the full AspectJ language, supporting any mixture of code and annotation style development.

AspectJ 5 will also have extended deployment options for load-time weaving, supporting aop.xml deployment files in the style of AspectWerkz.

AspectJ 5 users have access to a strong and growing set of books, articles, educational materials, training and consultancy. The following is just a selection of the books published or soon to be published:

In addition, AspectJ 5 benefits from a wide body of research, ranging from core aspect-oriented programming and design, to tools support such as refactorings, and an additional compiler called abc (4) for the AspectJ language developed jointly by Oxford University, McGill, and Aarhus University.

An increasing number of universities are also now teaching aspect-oriented programming courses using AspectJ, creating a flow of students into industry with knowledge of AOP.

 Frequently Asked Questions
  1. What does it mean for AspectJ 5 to support more than one development style?
  2. Why should an existing AspectJ user be interested in the @AspectJ annotations?
  3. Can I use both the code style and the @AspectJ annotation style in the same application?
  4. Will AJDT support the new annotation-based style?
  5. Will I be forced to use Eclipse to develop AspectJ applications?
  6. How hard will it be to port existing AspectWerkz applications to AspectJ 5?
  7. When can I begin moving my AspectWerkz applications to AspectJ 5?
  8. What about the doclet syntax that AspectWerkz supports?
  9. Will AspectJ 5 support aop.xml deployment descriptors?
  10. Will you support an XML syntax for defining aspects too?
  11. Will the existing AspectWerkz releases continue to be supported?
  12. What will happen to the AspectWerkz project / website / ... ?
  13. Will the compile/weave/runtime performance of AspectJ be impacted?
  14. Our company relies on AspectJ, will all these changes destabilize the implementation in any way?

1). What does it mean for AspectJ 5 to support more than one development style?

The code style and the annotation style using the @AspectJ annotations are just two alternate spellings for the same semantics. The same compilation, weaving and tools support will be used for both - and anything you learn in one style will transfer easily into the other.

Users who are not able to adopt the code-based style of development will be able to continue developing in a familiar style, but take advantage of the AspectJ 5 tools and the large body of training materials around the AspectJ language - since examples written using the code style will readily move across into the annotation style.

The following example shows a simple AspectJ aspect written using the existing code style.

            public aspect Authorization { 
            
              pointcut restrictedOperation() : execution(* IRestrictedAccess+.*(..)); 
            
              before() : restrictedOperation() { 
                  // verify caller is authorized to access this 
                  // operation ... 
              }
            }
        

Using the @AspectJ annotations, the same aspect may be written as:

            @Aspect 
            public class Authorization { 
            
              @Pointcut("execution(* IRestrictedAccess+.*(..))") 
              void restrictedOperation() {}
            
              @Before("restrictedOperation()") 
              public void verifyAccess() { 
                    // verify caller is authorized to access this 
                    // operation ... 
              }            
            }
        

The important thing to note here is that both programs mean exactly the same thing - they are semantically equivalent. They will both be treated in an identical manner by the compiler, weaver, and IDE tools.

Though we doubt this mix will be recommended, you could also use the annotation style and the code style in combination within a single source file - since they are both part of the one single AspectJ language.

2). Why should an existing AspectJ user be interested in the @AspectJ annotations?

An existing AspectJ user may benefit from the @AspectJ annotations when introducing AspectJ to a project where the team are not able to change IDE, compilers etc.

The @AspectJ annotations will be easier to work with in tools such as IntelliJ that do not yet provide any AspectJ support.

The @AspectJ annotations will be less likely to interfere with non-AspectJ aware source code processing tools that your project team may use.

3). Can I use both the code style and the @AspectJ annotation style in the same application?

Yes. You will be able to use aspects developed with the code style and aspects developed with the @AspectJ annotations in the same application. Combining these within the same source file will be possible but not recommended.

4). Will AJDT support the new annotation-based style?

Yes. Eclipse itself will provide support annotations on Java classes as part of its Java 5 support. The AJDT crosscutting views will work for programs developed using any combination of the styles.

5). Will I be forced to use Eclipse to develop AspectJ applications?

No. The AspectJ project is strongly committed to providing developers the tools they need whether they use an IDE or not. AspectJ has always included a command-line compiler and dedicated support for ant builds, and this will not change with AspectJ 5.

6). How hard will it be to port existing AspectWerkz applications to AspectJ 5?

The @AspectJ annotations have been designed to be as close as possible to the AspectWerkz syntax, while still preserving the semantics of the AspectJ language.

7). When can I begin moving my AspectWerkz applications to AspectJ 5?

Programs written for AspectWerkz will be able to be ported to use the @AspectJ annotations from the 1.5.0 release onwards (currently planned for March 2005). Support for some of the existing AspectWerkz deployment and runtime facilities will be available at that time, with further enhancements coming in follow-on releases.

8). What about the doclet syntax that AspectWerkz supports?

Doclet support is not planned for the initial 1.5.0 release, but is a relatively easy extension once support for the @AspectJ annotation style has been implemented. We plan to make this feature available in a follow-on release shortly after 1.5.0.

9). Will AspectJ 5 support aop.xml deployment descriptors?

Yes. The XML-based deployment descriptors are an important piece of the J2EE integration story. AspectJ 5 will also support configuration via aop.properties files for environments where an XML parsing infrastructure is not available.

10). Will you support an XML syntax for defining aspects too?

AspectJ 5 will provide support for defining concrete sub-aspects in aop.xml files. These must extend existing abstract aspects, and provide definitions for all abstract pointcuts defined in those aspects. See the AspectJ 5 Developer's Notebook for more details.

11). Will the existing AspectWerkz releases continue to be supported?

Yes. There will be an AspectWerkz 2.0 final release, and this will be supported. We will ensure that the migration path from AspectWerkz 2.0 to AspectJ 5 is as smooth as possible.

12). What will happen to the AspectWerkz project / website / ... ?

It will remain hosted and maintained at http://aspectwerkz.codehaus.org in support of the AspectWerkz releases. Information relating to AspectJ 5 will be on the AspectJ website.

13). Will the compile/weave/runtime performance of AspectJ be impacted?

No. Our target is for AspectJ 5 compile / weave / runtime performance to be as good or better than what can be achieved with AspectJ 1.2 today.

14). Our company relies on AspectJ, will all these changes destabilize the implementation in any way?

No. The changes described in this documented are incremental changes on top of the existing AspectJ codebase.

 References

[1] AspectJ

[2] AspectWerkz

[3] AspectJ 5 Developer's Notebook

[4] The AspectBench Compiler for AspectJ

 Trademarks

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.