IntroductionToAspectOrientedDevelopmentInJava

Aid maintainability by de-cluttering source code
Might be useful for checking parameters and return values during development (but Java assertions might be more natural)
Lots of scope for new, subtle bugs
Ordering of aspects is critical, because they influence one another, but it is not always obvious how to control the ordering
Probably not ready for mission-critical applications
Legacy code might invite major refactoring to use aspects
Worth investigating what support for aspects exists in other languages, particularly C# (see also http://portal.acm.org/citation.cfm?id=1052898.1052907 - Aspect<nop>Cobol!)
We're still trying to find real-world examples of its use (but see end of this page)

The application main() method has to initialise the aspect system explicitly, which breaks the "non-invasive" principle

it may be possible to devise an XML schema and pre-processor that generates this initialisation code automatically and inserts it in main()

Because initialisation only nominates the aspects to apply to each class, the aspect methods themselves have to work out whether they apply to any particular method using if/then/else

this is clumsy and obscures the purpose of the aspect method
it can be parameterised to some extent by passing method names as constructor arguments to the aspect classes (we tried this and it worked)

Even with a working example to look at, creating a new aspect was quite hard work and took half an hour or more
The tool is more of a proof-of-concept than an industrial-strength tool and possibly won't evolve now that Aspect<nop>J, Aspect<nop>Werkz and Spring are maturing
Little or no documentation available

Easier than JAdvise, once examples are available (we took only 10-15 minutes to implement the Singleton exercise after taking nearly an hour over JAdvise)
Powerful in terms of method signatures that can be advised - JAdvise can only advise methods that return an Object, it appears
Documentation is scrappy - some tutorials, some of whose examples do not work; no proper reference manual (yet) or books

the separate XML configuration files supported by Aspect<nop>Werkz are more powerful for separation of concerns

Aspect<nop>J is probably the one to watch, particularly now that it is merging with the Aspect<nop>Werkz tool.

http://www2.cs.ucy.ac.cy/~george/SAC04b.pdf - an evaluation of AOP in the development of a high-performance component-based web-crawling system, which compares the process with the development of the same system without AOP. The results of the case study mostly favor the aspect oriented paradigm.
http://portal.acm.org/citation.cfm?id=1052898.1052902 - by adding a Qo<nop>S aspect package to an existing system without Qo<nop>S guarantees, the authors were able to use the same system in unpredictable environments where performance guarantees were essential. Furthermore, by exchanging aspects within the Qo<nop>S aspect package they were able to efficiently tailor the Qo<nop>S management of a real-time system based on the application requirements. In a case study of an embedded real-time database system, called COMET, they demonstrated how a real-time database system could be adapted for use in different applications with distinct Qo<nop>S needs.
http://www.info.ucl.ac.be/people/PVR/aopabstract.html - abstract and presentation slides of a talk given to the Belgian Symposium and Contact Day on Software Evolution and Aspect-Oriented Programming. Ghent, Belgium, May 3, 2004, which caused a bit of a stir - it showed how the application architecture had to change with each new aspect, because it increases the complexity of the system.

Contents