[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] AspectJ and JBoss AOP implementation
|
Ruud Steeghs said:
>
> AspectJ introduces a new language (AspectJ) with new
> keywords, compiler and stuff. (There's great IDE
> support for AspectJ).
> JBoss AOP is configured in XML.
Thanks for bringing this up.
This is one of the most common reasons I hear for JBoss being
easier to learn than AspectJ. But I think its worth pushing on
a bit.
As I see it, ALL these AOP tools introduce a new language. The
difference is really in where that language is "hosted", and
what consequences that has for how its compiled (and/or
interpreted). I think this looks something like:
language host compiler
AspectJ Java javac replacement
AspectWerkz
doclet syntax Javadoc new pre/postprocessor
attribute syntax JSR 175 new pre/postprocessor
XML syntax XML new pre/postprocessor
JBoss XML new pre/postprocessor
In AspectJ people clearly see it as a language, because its an
extension to the Java language. In the other tools you may not
immediately see it as a language, but it is.
The languages themselves are all fairly similar, since AspectWerkz
and JBoss are modelde on AspectJ.
So I would argue that the "new language" issue is a red herring.
Its often repeated, but it isn't quite right.
So then the question is, if you're going to have a new language
for describing the crosscutting structure of aspects, would you
rather have that embedded in the existing OO language (Java) or
as a bolt-on. I can actually see arguments either, although I
clearly prefer the embedded in Java solution personally!
What do people think of the above argument? Again, I'm not trying
to start a flame war. But I think it behoves ALL AOP proposals to
have a clearly worked out understanding of the relative strengths
and weaknesses, including how easy they are to learn.