The AOP Alliance Claim

Most of the people here do not believe in the perfect system. We think that a system is always suited to a given problem and environment (it does not necesseraly fit the other one). This is exactly the case for the AOP tools that we may use within complex environments such as J2EE. Depending on the faced problem, it would be useful to have a specific implementation of AOP.

There are already a lot of specific implementations of AOP or AOP-related techniques such as generic proxies, interceptors, or bytecode translators. For instance, among others:

• AspectJ: an AO source-level (and bytecode-level) weaver. New Language.
• AspectWerkz: an AO framework (bytecode-level dynamic weaver+configuration in XML).
• BCEL: a bytecode translator.
• JAC: an AO middleware (bytecode-level dynamic weaver+configuration+aspects). Framework.
• Javassist: a bytecode translator with a high-level API.
• JBoss-AOP: interception and metadata-based AO framework (running on JBoss application sever + a standalone version).
• JMangler: a bytecode translator with a composition framework for translations.
• Nanning: an AO weaver (framework).
• Prose: an AO bytecode-level dynamic weaver (framework).

To us, these implementations reflect that there is no good or bad implementations, but implementations suited to some problems/environments.

So, the AOP Alliance goal is neither to come with a new AOP model, nor to provide a great AOP implementation that will work for all the cases or on a given J2EE application server. The AOP Alliance goal is rather to enable all the exisiting implementations to speak the same core language in order to:

• avoid re-building of existing AOP components by reusing them,
• simplify the adaptation of existing AOP components for a given target environment (typically a J2EE environment),
• simplify the aspects reusing by having a common root AOP API.
• simplify the implementation of development tools that whish to integrate AOP features.