The track started with Gregor and Adrian's talk on adopting AOP. This was great and well worth drawing from if you are presenting on this topic in your own organization! The presentation had some great examples from internal use at IBM, notably examples of how it allowed system architects to refine the policy for error handling, which was never possible to vary before and the ability to vary features in product lines. Gregor also raised the great ideas of modularizing quality of service and doing clean room system extensions. The slides from the keynotes and the industry track are being posted at https://www.aosd.net/archive/
The basic approach of building up from exploration and enforcement to auxiliary/infrastructure to core/domain-specific is fairly proven. I find managers and architects who are interested often want to "spike" ahead and get help to prototype a compelling production use case too. I am also seeing more interest in analysis, design, and strategy for longer-term use. I also really like the graphics and their emphasis on being modest in claims, since people often want to hear about silver bullets. In particular, they wrap up classes with a slide about "What makes a good aspect," to emphasize that aspects should be used to solve hard problems modularly, i.e., to improve the design & implementation.
Then Adrian and Jonas talked about what's new in AspectJ 5, covering how AspectJ and AspectWerkz came to merge, and showing examples of how it will support annotations, generics, and other Java 5 language features. The use of type erasure with generics eliminates runtime type information, which makes it harder to use pointcuts. I won't even try to recap this material: take a look at the AspectJ 5 developers handbook for more detail.
This talk and Jonas' talk on the road to AspectWerkz 2, also covered the origins and implementation for AspectJ 5 of classloader-aware load time weaving (aka LTW) and @AspectJ syntax.
Classloader-aware LTW means you can deploy an aspect to a classloader and it will weave into only classes loaded from that loader (or below in the hierarchy). It will be using Java 5 agents and JRocket agents. I spoke to Alex and Jonas subsequently and think we'll see options for deployable Java 1.3 and 1.4 LTW support that works with containers, too. The ability to use aop.xml to control weaving and to apply abstract aspects are great too.
Jonas also showed the @AspectJ annotation, which brings the Aspectwerkz annotation-defined syntax to AspectJ (I had suggested this approach to Jonas and it became the more popular syntax for AspectWerkz users). I also expect to benefit from using it on a project for a customer where everyone uses IntelliJ IDEA.
Jonas also presented the work they did on runtime weaving with HotSwap, programmable per-instance deployment, the extensible aspect container, including a very high performance pure proxy-based AOP implementation, and on the AW Bench AOP performance benchmark.
Sam Pullara asked a great question about how AspectJ's annotation support will work with apt. Adrian noted that you can run apt first, then weave the result with AspectJ. However, it's a good question, because there won't be support for processing the results of declare annotation with apt. I also wonder how Eclipse will provide good IDE support for apt tools; I see the Pollinate project was discussing how Eclipse should work with apt; hopefully they will lift their consideration from making it work to first-class tools support...
Nicholas Lesiecki presented some great information from his team's experiences adopting AOP at VMS:
They first added support for logging initial exceptions for certain popular Web frameworks that don't do exception chaining (e.g., Apache JSTL). This was quite helpful, although allowing after advice on handler join points would have made it much better. I think AspectJ needs to capture additional bytecode metadata to capture enough information to allow weaving properly in the case that the original source was compiled by an AspectJ compiler.
Nick emphasized the importance of the design pattern whereby aspects uses helper class(es) to do the heavy lifting. This makes it easier to inject alternatives, ease tools use, and aids in testing.
They next implemented a basket repricing aspect for e-commerce. This aspect affects 12 points in 3 classes: they have significantly refactored it 4 times, with a 5th underway at the time (based on a new marketing requirement). This is a key benefit of aspects: they would have never felt free to refactor this way in a tangled implementation.
Nick also presented some great aspects that work with Hibernate. They auto-register hibernate objects with open sessions and most impressively, built a fairly generic aspect to implement relationship management (like CMR) for Hibernate. This affects 93 places in their application. It tok took 2 weeks to write. This prompted Merrick Schincariol of Oracle to question whether it was worth it for a single project: I think it depends on how much time it saved in fixing bugs, although maybe a simple enforcement aspect would help a lot. I think an aspect like this that is tightly coupled to a framework is most valuable when reused and is best supplied by the framework itself.
The team adopted AOP fairly easily and quickly: it took 6 months of project time in which 5-10% of development effort was devoted to learning it. By contrast, the project also converted to Tapestry and Hibernate and both were stop the world adoptions. However, aspects were often suspected as a red herring cause of other problems. My code doesn't work? Blame AOP!
Ramnivas gave a great presentation of annotations and AOP, and Mik gave a great presentation comparing the leading AOP tools. Both of them have written two part articles in the http://www-128.ibm.com/developerworks/views/java/libraryview.jsp?search_by=AOP@work: series on IBM Developerworks. I'd encourage you to read them for more details!
