Women in Technology

Hear us Roar



Article:
  Aspect-Oriented Programming and JBoss
Subject:   Why inventing new AOP and not using existing one?
Date:   2003-06-03 00:04:05
From:   mszklano
Hi!


I am AOP passionate for about half a year. I wonder why you decided to invent the whole new AOP concept and implementation instead of using existing, mature frameworks like AspectJ.


AspectJ exists here for several years, has proven its value, is used in several production environment, and, IMHO, provides better flexibility when talking about AOP, than your implementation.


Or maybe your point-of-view is different? Maybe you chose declarative programming instead of messing up Java code with syntactic additions?


Could you please answer my question?


Second, this article, you have posted to OnJava is just the tip of iceberg. You claim to implement some very interesting aspect inside JBoss 4.0. Maybe you can share this knowledge in next article. It would be extremely interesting to see how you implementation of AOP works in real productiona environment...


BTW. why you guys have not registered JBoss AOP as AOP implementation on aosd.net?


Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Why inventing new AOP and not using existing one?
    2003-06-03 07:52:34  patriot1burke [View]

    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.

    Bill