IntroductionToAspectOrientedDevelopmentInJava
From SPA Wiki
Contents |
Introduction to Aspect Oriented Development in Java
Session leaders: ImmoHuneke, CornelStudach
Participants:
- KarelRiha
- James (Robertson?)
- James Shade
- Ronald Marciniak (sp?)
- Susan Duncan (Oracle)
- Pippa [] (Oracle)
- MarkCranshaw
- JohnFlackett
- ScottCrawford
Findings
All tools
- 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)
JAdvise
- 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
Aspect<nop>Werkz
- 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
Aspect<nop>J
- Best documented tool of the lot - lots of manuals and books
- Best Eclipse support
- A neat way to extend Java (annotations found expressive)
- Aspects are all compiled-in, so have to change source code to change them
- the separate XML configuration files supported by Aspect<nop>Werkz are more powerful for separation of concerns
- Separation of concerns
- "cool"
- but "scary"
- breaks encapsulation - you can advise private methods including constructors!
- Reasonably easy to use (particularly the annotations)
Conclusion
Aspect<nop>J is probably the one to watch, particularly now that it is merging with the Aspect<nop>Werkz tool.
List of references to real-world experiences
- 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.