News: AspectWerkz 2.0.RC2 is released with an Eclipse Plugin

  1. AspectWerkz 2.0.RC2 is out, with some new features like a programmatic per instance interception framework, and the new proxy framework that enables use of aspects with straight proxy hidding the usual compilation / weaving phase needed in the AOP world and without requiring any proxy specific syntax in the pointcut expressions.
    The proxy framework also comes with a CGLIB extension, so that CGLIB proxies can be made AspectWerkz aspects aware out of the box.

    The AspectWerkz team has also shipped a simple Eclipse plugin that provides markers in the source code where advices are applied and embeds its annotation compiler to simplify the user experience of those running with Java 1.4 and defining aspects using doclet annotations.

    Read the release note
    Read more about the Eclipse plugin
  2. First, congratulations. I'm especially impressed to see IDE support for aspectwerkz - question: are there any plans to extend the Eclipse support beyond annotations to XML definitions? I would think in a lot of scenarios you'll end up with both statically/compile-time and dynamically/run-time woven aspects, so it'd be great to get some idea in the IDE of which aspects are applied to a certain method ... (given the aop.xml is in the classpath).
  3. The released plugin takes into account any aop.xml that it founds in the project classpath and gives markers and "advised by" indication.
    It thus takes into account any kind of aspect packaged around (source available or packaged jar file in the project classpath with aop.xml inside), and any style of aspect (annotation defined, xml defined, and xml refined).

    I may give a try to have it working with the AspectWerkz extensible container, which should give support out of the box for "advised by" indication for other kinds of aspect supported there (Spring, AOP alliance, and a subset of AspectJ - for this last you may need the AJDT plugin to write the aspect, or stick to use of compiled AspectJ aspect in the classpath)

  4. Congradulations.

    One of the major obstacles for us to use Aspectwerkz was the performance. We experienced that Aspectwerkz (in both modes) was much slower than AspectJ, and because of the performance penalty, the project was inclined toward AspectJ. Have you done any major performance improvement?

  5. The runtime performance of AspectWerkz 2.x is far better as compared to AspectWerkz 1.0, and very similar to the one of AspectJ.
    Around advices are a bit slower since we don't inline them to support more dynamic AOP constructs (hot deployment of aspect, programmatic per instance interception).
    In other case both AspectJ and AspectWerkz ranks first as compared to JBossAOP or proxy based lightweight AOP.

    We have released the figures as part of a generic micro benchmark initiative some weeks ago.
    Report is here.

    As regards weaving performance and memory footprint I don't have figures yet. Weaving performance may be of interest only when dealing with tool support or when using load time weaving instead of post compilation. Simply note that AspectWerkz 2.x is based on ObjectWeb ASM bytecode kit, which claims to be significantly faster than BCEL or Javassist. ASM is used in CGLIB as well.