Dion is excited by the proliferation of AOP talks at the NFJS symposiums. Cedric remains skeptical about the adoption of AOP.

Many developers have an itch they aren't entirely aware of. Repeated boilerplate code causes it. AOP can scratch it. I survived without OOP for a long time, but now that I'm aware of it, and I understand it, I have no desire to go back. The same happened with AOP to a lesser degree. Whether others choose AOP or some other road, I'm confident the itch will get scratched. It's just a matter of time. Developers who understand AOP will open others' eyes to how they can improve their code, and they will in turn open even more developers' eyes. Pay it forward. I've witnessed this effect in my own company as interest in AOP slowly but surely snowballs.

In regard to alternate roads, annotations (assuming I understand them correctly) have the potential to partially supplant AOP, solving some problems in a less powerful but simpler manner. Take undo logic for example. I can use AOP to pick out undoable methods and apply undo logic to them completely independent of the target code. Or, I can just add @Undoable annotations in the source code of the undoable methods and inject the undo logic at compile time (generating undo command classes, etc.). The annotation-based approach isn't as concise as an AOP-based implementation, but some might argue that it's more maintainable.