I don't actually have any flames for the Posse's AOP response, but Dick 
predicted flames, so I had to put that in the subject :-)

My own take is that unbridled AOP defies all normal programmer 
understanding.  As one or more of the Posse said, looking at the code 
and finding it doing something quite different is far too magical.  This 
defies comprehension, maintenance, and troubleshooting.

There certainly /were /use cases for AOP, but many of these have been 
tackled by libraries/frameworks that use AOP but do so in a bridled 
fashion where a combination of annotations and 
limited/restrained/controlled magic make the results predictable and 
comprehensible.

Use cases for raw AOP, as opposed to AOP tamed and targeted by a 
library/framework, are very limited.  They do exist, but fall into 
categories like dynamic troubleshooting, rather than architecting 
software.  For instance, if you need to add logging (that no one foresaw 
the need for) to a production system without changing any existing class 
files, AOP and load-time weaving can be just the ticket.  Of course even 
there btrace seems like a more targeted and controlled than raw AOP 
solutions like AspectJ -- though AspectJ certainly works here.  
Similarly, while one could use raw AOP for mocking in unit tests, 
jmockit is more targeted, controlled and high-level.

So what is AOP good for?  It's a powerful tool for building certain 
types of library/framework capabilities.  Also there are those rare 
cases where you want to make a set of magical changes across a set of 
classes where you don't need or want this exposed for comprehension, 
maintenance, or troubleshooting -- but that's really, really rare.  In 
both of these use cases, AspectJ seems to fail -- the result of its 
changes are too heavy and clunky (adding numerous levels to call stacks 
for around advice, for instance) and its weaving performance is 
sub-optimal.  Lower-level byte-code weaving libraries like ASM, 
Javassist, and cglib are critical underpinnings to various higher-level 
libraries, frameworks, and containers in use today, however (just take a 
look inside many a jar to find a repackaged ASM inside...)

--
Jess Holle


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to