TSSS: Quick notes from AOP Keynote Panel

17:00 - 18:30

Gregor Kiczales, Rod Johnson, Adrian Colyer, Ron Bodkin, Cedric Beust, Bob Lee, Bill Burke, Marc Fleury, Dion Almaer

Gregor: What AOP is not. It is not a particular framework. It is not about particular implementation. Objects have changed our thinking about application development. Aspects are going to change the way we think. At the same time, the impact will also be slower because of it.

Rod: AOP is mature enough to use it right now. It is going to make our lives so much easier that it is irresponsible not to use it. AOP will be a superior replacement for EJB. The concept of a container is a subset of AOP that can be using by any existing AOP framework. AOP makes it easier to implment things like transaction management (e.g. programmatic TX mgmt is a lot of boilerplate code). Spring is a "pragrmatic AOP" framework, is used in production -- it is a true AOP not just a simple interception because it includes pointcuts. Declarative transaction mgmt is a killer application for AOP. Spring is a non-invasive framework: dependency injection (but it is not enough) + crosscutting concerns. Declarative transaction management is working out of the box.

Adrian (leads AspectJ/eclipse integration project): helping to use AOP at IBM. All product groups within IBM are looking to apply AOP and AspectJ in their areas. Middleware -- the purpose of middleware -- help in developing distributed applications (e.g. Transaction Manager, etc). At the same time it is impossible to hide all details. NITPicking (Non Invasiving Technologies) applications.

Ron: Things have gotten too complicated -- how we solve it. Code generation is one of solutions. There is a learning curve: new patterns start to emerge. Refactoring: applying aspects to small subset of code before applying to all 500 classes. Aspect can be reusable and it is very easy to use them out of the box -- you don't have to go and add the tags all over your code.

Cedric: Conflicting views on AOP. Things are progressing but slowly -- we still don't see major adoption for such a great technology. Like TiVO - it is a great technology but it is hard to explain to someone else and get him excited about it. AOP/Groovy/Annotations - java but itself is not enough in the enterprise. AOP can do the same thing GoF patterns did -- create a new language for developer communication.

Bob: Dynaop -- a conservative approach to AOP. It works in any environment (app server, app). Does not have ClassLoader issues. Can create proxies on the fly. Interoperation with Spring (AOP Alliance interfaces). Abstract advice feature (Richard Oberg) -- static AOP.

Bill: Dynamic AOP -- going deeper to work with POJOs. JDK 1.5 annotations is very important for JBossAOP.

Marc: Untangling the code (IDE demo at AOSD). The middleware is a collection of aspects. How do we offer all this services? EJB offered 6 aspects but the model was very intrusive.

Ted Newart - Q on stateful aspects

Howard Lewis Ship - Q on debugging support support.

• Adrian: AJDT supports debugging in eclipse.
• Rod: AOP simplifies your code and makes code less error-prone. Also, you can actually set breakpoints in aspects.
• Bill: It is much easier to write unit tests using AOP approach. You can inject exceptions.

Aslak Hellesoy - Q - what is it that help AOP adoption.

• Marc: you won't see millions of AO developers. At the same time there will be millions of AO users.
• Cedric: writing advices and pointcuts is hard. As long as it is hard it will be limited to middleware vendors. We need an easier, VB-like way.
• Gregor: it is going to take all of these things: tools, frameworks, libraries, time. IBM is committed to this -- if IBM using it, it will support it forever. Java went fast but it was in a tide economy.
• Rod: It might be opposite (about the economy) as AOP allows to implement things cheaper. Incremental technology adoption has its own benefits (sense of security) and it is happening.
• Adrian: over last 18 month spent a lot of time introducing AO to new people. People understand it better when they see actually it -- just telling doesn't necessarily stick.

Cedric: we should use magic only when the science fails

Gregor: it is a natural thing to not to limit crosscutting concerns to a signle language