Let me talk a little bit about AspectJ. AspectJ's been around for 4 years; they're really the original creators of aspect oriented programming. They're the ones who really said, "Well, interceptor technology, introductions, all that stuff-this is AOP". They really defined it. So AspectJ's been around for 4 years so they have a very extensive point cut language. But that point cut language is described in an extension of Java. You have to compile it before runtime. The reason why JBoss 4 did not use something like AspectJ is that we wanted to do things dynamically at runtime. The caching stuff I talked to you about was a perfect example.

When an object is inserted into a JBoss AOP cache we apply aspects at runtime rather than at compile time. So that's one of the things that AspectJ can not do, that we do with JBoss 4-applying aspects at runtime. Another thing is that, if any of you have used JBoss Application Server, you'd have noticed that there's never any compiler step for EJBs. We wanted to take that into JBoss 4 with aspect oriented programming as well. We do not want to have a compilation step. Another thing is that, if you've ever used JBoss itself, you know that any service, any component, any class is hot deployable at runtime. We wanted that they would have aspects that can be hot deployed as runtime aspect components. So those are the reasons that (in) JBoss 4, we wanted to write our own framework instead of using something like AspectJ.