AOP Alliance (Java/J2EE AOP standards)
Aspect-Oriented Programming (AOP) is a programming technique
that will be able to enhance several existing middleware
environments (such as J2EE), or development environements
(e.g. JBuilder, Eclipse).
Several projects now provide AOP-related techniques such as
generic proxies, interceptors, or bytecode translators.
ASM: a lightweight bytecode
AspectJ: an AO
source-level weaver. New Language.
AspectWerkz: an AO
framework (bytecode-level dynamic weaver+configuration).
BCEL: a bytecode
CGLIB: high-level API for class artifact manipulation and method interception.
JAC: an AO middleware
(bytecode-level dynamic weaver+configuration+aspects). Framework.
a bytecode translator with a high-level API.
interception and metadata-based AO framework.
a bytecode translator with a composition framework for translations.
Nanning: an AO weaver (framework).
Prose: an AO
bytecode-level dynamic weaver (framework).
... and many others (email me to add a new one)
All these projects have their onw goals and
speficities. However, several common basic components are still
usefull (and sometimes required) to build a full AO system. For
instance, a component that is able to add metadata on the base
components, an interception framework, a component that is able
to perform code translation in order to advice the classes, a
weaver component, a configuration component, and so on.
To us, it would be great to be able to reuse different
components coming from different projects to build a full AO
system, and for three main reasons.
- Firstly, several components
already exist and it would be stupid to rebuild them.
various implementation of the same component may be useful and be
more-or-less suited depending on the environement. For instance:
the program tranformation can be done at a bytecode or a
the source-code level, at compile or at run time, using an
interception or a code insertion mechanism depending on
the implementation of the component that translates the
- the weaver may be used within a
standard Java context or within an EJB context, which may
imply some implementation differencies
Thirdly, having common interfaces and components would help in
reusing aspects on different weaving environements... this
will greatly improve sofware reusing.
For these reasons, we think that a standarization of the
interfaces of the aspect-oriented components would be great and
will bring great simplifications for the entire AOSD community,
but also for all the communities that will to use AOP in a close