I have done quite a lot with Spring and AOP in the past (have been a long time Spring supporter), but every time I need it in a project and look at the reference documentation, I find it more and more confusing and getting too complex for day to day use (especially if not every team member is a Spring expert). It is not because I don’t understand AOP:
– I have used it for quite some time
– I do quite a lot of bytecode manipulation on the Multiverse project.
What is wrong with Spring AOP?
– everything can be combined with everything in all kinds of different ways (so too many permutations)
– there are 10.000 ways to configure it and the configuration can be spread all over the place (including in the source).
– Spring documentation (which is very detailed) is not written in a way to get you up and running fast (so a complete working copy/paste hello world solution).
– bytecode weaving of AspectJ gives problems with load time weaving (administrators, influences other applications on the same jvm) but compile time weaving in combination with Maven also gives problems because the bytecode is modified before the unit tests are executed.
It doesn’t mean that Spring AOP is bad from a technology point of view, but it certainly is bad from a productivity point of view. I love to solve complex problems, but I don’t like to solve problems that are needlessly complex. And Spring AOP imho is a good example of Spring becoming the problem it tried to solve: needless complexity.
Blog of Peter Veentjer 
It’s open source. If documentation is the problem, write up your own and contribute it. I don’t find it any more confusing than AspectJ.
Hi John,
thanks for your comments. The problem is that it is more than just a documentation issue. The whole Spring AOP design is very complex.
I agree that AOP has to be used wisely. It can confuse team members how are not familiar with the technique.
I dont agree that Spring AOP is complex. Im using annotation based AOP with Spring, e.g. @Aspect, @Around, …
And Im using Spring IDE for Eclipse which directly marks pointcuts in the java editor, so you can see whats going on even without having each and every aspect in mind.
Hi,
I dont agree that Spring AOP is too complex. If you use the annotations approach the code is clean. Saying that it is complex beacuse there can be many ways to configure AOP in Spring is not correct. I actually shows that Spring is indeed flexible in terms of how Aspects can be configured.
Having many configuration options always increases complexity. It could be that the added complexity reduces complexity somewhere else, but it still is more complex than having less options.
And I love options and I love complex stuff, but I don’t want to see complexity where it has no value. The original AspectJ library was reasonable usable, but imho the whole Spring AOP functionality (not just AspectJ) is too complex for the value it provides. There must be a simpler solution (I think that with new languages like Scala the whole need for Spring AOP will decrease a lot). In a few years we will all realise that it was too complex, just like EJB 2 🙂
Couldnt agree more, in fact i wanted for a long time to write a blog post about the many ways you can use the spring aop and transactio apis.
And i also agree the overall design is complex. The question is that when you have too many ways to do the same thing, would you be interested in learn all of them to choose wisely, or the first one that works?