JBoss AOP v.s AspectJ 5: Part 1

/ damnhandy

Before I started getting into AOP, I wanted to know what the real differences between AOP implementions. Sure, we all know that AspectJ is a language extension and JBoss AOP can be done in all Java. Ask folks on the JBoss forums give you a JBoss-biased answer. Similarly, some of the IBM Developer Works articles (particularly this one) are a little dated and still have a bias toward AspectJ.

But aside from that, what makes one implementation better than the other? Is one easier to develop with? Easier to deploy? Personally, I’m still trying to figure this out and I thought I’d share some of my findings. I will state up front that initailly I was a bit more bias toward the JBoss AOP implementation. Now that AspectJ 5 has been released and it supports Java 5 and annotations, I’m seeing things a bit differentlty. Part 1 looks at the differences between IDE plugins. Part 2, which is still in development, will look at the differences implementing the same aspect in both implementation. Enjoy!

8 thoughts on “JBoss AOP v.s AspectJ 5: Part 1”

  1. If you re-read the page eu, you’ll see that I do mention creation AspectJ aspect using annotation Driven development. In fact, my next post on the topic covers this extensively. I did not mention AspectJ’s XML pointcut definition since I haven’t used that feature yet and second, I don’t see the need to. Just FYI.

    Like

  2. If you re-read the page eu, you’ll see that I do mention creation AspectJ aspect using annotation Driven development. In fact, my next post on the topic covers this extensively. I did not mention AspectJ’s XML pointcut definition since I haven’t used that feature yet and second, I don’t see the need to. Just FYI.

    Like

  3. Your information about AspectJ is quite outdated. It also support annotation driven aspects and they can be defined in xml file. I guess currently there are no practical reasons to use JBoss AOP…

    Like

  4. Your information about AspectJ is quite outdated. It also support annotation driven aspects and they can be defined in xml file. I guess currently there are no practical reasons to use JBoss AOP…

    Like

  5. Considering the AOP user forum is only about a month or old, It’s now wonder it appears deserted. The user forum was created due the fact that users were posting too many questions to the developer forum and apparently many folks have yet to catch on 🙂

    Like

  6. Considering the AOP user forum is only about a month or old, It’s now wonder it appears deserted. The user forum was created due the fact that users were posting too many questions to the developer forum and apparently many folks have yet to catch on 🙂

    Like

  7. It’s no longer a matter of which one is best. AspectJ is the de facto standard and hardly anyone users JBoss AOP (see their deserted forums).

    And actually, I happen to think the merge of AspectJ/Aspectwerkz is orders of magnitude cleaner and more powerful than JBoss AOP anyway. For once, we have a defacto standard that’s actually good, let’s all use it 🙂

    Like

  8. It’s no longer a matter of which one is best. AspectJ is the de facto standard and hardly anyone users JBoss AOP (see their deserted forums).

    And actually, I happen to think the merge of AspectJ/Aspectwerkz is orders of magnitude cleaner and more powerful than JBoss AOP anyway. For once, we have a defacto standard that’s actually good, let’s all use it 🙂

    Like

Comments are closed.