[aspectj-users] AspectWerkz vs. AspectJ]

[Chad Woolley <lists@xxxxxxxxxxxxxxxxx>]

Hi,

I posted this on the AspectWerkz mailing list (http://aspectwerkz.codehaus.org) 
when asked to by Jonas Boner (AspectWerkz creator).  Nicholas Lesiecki suggested 
I post it here also.

Thanks,
Chad


---------------------------------

Jonas Bonér wrote:
> I have seen that you are using AspectJ as well. I would appreciate (if
> you have time) some comments on the drawbacks/problems/limitations using
> AspectWerkz compared to AspectJ as well as the good things and
> advantages. I want to constantly improve. :)
>
> /Jonas

Jonas,

I am planning to have VirtualMock support both frameworks, and allow the
user to choose.  I think this will be an interesting example of how to
support a "pluggable" AOP framework.  In my app, I have abstracted out
the aspect support to a thin layer consisting of only the advice and a
custom helper class.  This layer can use either AspectJ or AspectWerkz
to accomplish the same thing.

I'll first make this disclaimer:  My use of aspects in my app is very
simple and limited.  It's really all based around a couple of global
pointcuts.  AspectJ has a rich definition language, and could very well
have benefits over AspectWerkz that I am not aware of.


The biggest benefits of AspectWerkz I have found are:

1. The easy-to-understand definition language (XML/xdoclet).  AspectJ's
definition language is difficult to learn (at least it is for me).

2. The pure-java approach (as opposed to AspectJ's custom code-based
definition language).  If you are doing test-driven development with the
associated heavy emphasis on refactoring, this is a big plus.  It's
great to use an IDE like Eclipse to do automatically do a major
refactoring, and have the confidence that all your advices were
refactored correctly as well.

3. Checked exceptions are not validated by the compiler, as in AspectJ.
 In some situations, compiler enforcement of checked exceptions may be
considered a benefit.  However, in my case, it was a pain, because I
used global advices and had no way of knowing what type of exception I
would be throwing.  In AspectWerkz, I simply return the exception.  In
AspectJ, I had to use BCEL to make a hacked function which allowed me to
throw any checked exception as a non-checked RuntimeException, without a
ClassCastException (many thanks and all credit to Ron Bodkin for the
idea).  It would be nice if AspectJ trusted you and gave you a way to
disable this compile-time checking.

4. Online mode (runtime weaving)!  I am still trying to bring everything
together, but I think that using "offline" mode (compiling new bytecode
from existing bytecode) in either AspectJ or AspectWerkz is going to be
a performance bottleneck.  My app is a unit test framework, so making
the user wait for a complete compile and weave before each test run will
be a big disadvantage.  I am anticipating that using AspectWerkz
"online" mode will end up being a much faster way to achieve the same
goal.  However, this does force you to deal with complicated issues
related to custom classloaders, multiple VMs, JDK versions, Sun
licensing agreements, etc.  For a framework that will be used by end
users, this can present some difficulty in making it user-friendly and
transparent (and legal!).


The DRAWBACKS of AspectWerkz that I have found are:

1. Weaving some classes makes AspectWerkz blow up, such as Log4J, JUnit,
and some core classes from Sun.  This is an important issue to deal with
when using global pointcuts.  As far as I have seen, AspectJ doesn't
have these issues (at least not with Log4J and JUnit).  Since my app is
a framework which will be used to weave any code the user specifies,
this brings up the obvious question:  Are there any other "problem"
classes lurking out there that I haven't found yet?  I still don't know
what the common factor is that causes the problems.

2. To be fair, I haven't tried this in AspectJ, so I don't know if it
would have the same problem.  The problem was that I wanted to define a
cflow pointcut and caller-side pointcuts in conjunction with a JUnit
testcase class.  You and I had a long email exchange on why this was not
possible, but I never fully understood the reason (not your fault at all
- you tried very hard to explain it to me :) ).  I think it was
something to do with reflection.  I ended up having to use a global
pointcut on the caller side instead.

3. Lack of IDE integration.  I am a heavy Eclipse user, and it is nice
to be able to use AJDT to compile, run, and unit test all my
aspect-based code from within the IDE.  However, to be fair, I still
find AJDT to be kind of flaky - sometimes it doesn't compile my code
when I tell it to, and I have to force a manual compile even when I have
the automatic compile turned on (this IS with the latest release).  On
another project at work, we have also found that there is something in
our aspects that causes AJDT to not compile anything, even though there
are no syntax errors reported (although we haven't tried the latest AJDT
release at work).  I may be doing something wrong, but in my opinion all
I should have to do it install it, or at least get a meaningful error if
I'm doing something wrong :)


All in all, I think AspectWerkz is great, and offers some clear
advantages over AspectJ for some situations.  However, it's still
maturing, and lack of IDE integration will be a big drawback for some
people.  The "problem" classes that cause AspectWerkz to blow up will
also be an issue for people using global pointcuts, but global pointcuts
should only really be necessary in certain circumstances.

Thanks for the great tool!

Chad

_______________________________________________
aspectwerkz-user mailing list
aspectwerkz-user@xxxxxxxxxxxxxxxxxx
http://lists.codehaus.org/mailman/listinfo/aspectwerkz-user