Why not AspectJ? Here's a few reasons:
1) There is no dynamic interface.
- Some of our aspects (like caching and acidity) require that some objects be advised at runtime.
- In the spirit of JBoss, aspects should be hot-deployable. That means you can add, remove, redeploy aspects at runtime while the system is active.
2) We wanted to have a metadata facility like JSR 175 tightly integrated with our Aspect framework. This allows us to pre-package aspects as metatags a la C#.
3) AspectJ requires a compilation step. JBoss has traditionally avoided compilation steps with EJBs and other components. We wanted AOP to be the same. So, we instrument the classes at load time. Another thought was that the industry may be wary of adopting an extension of Java.