aop "flames"

5 views
Skip to first unread message

Jess Holle

unread,
Jul 22, 2009, 10:56:37 PM7/22/09
to java...@googlegroups.com
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

Alan Kent

unread,
Jul 22, 2009, 11:51:35 PM7/22/09
to java...@googlegroups.com
Jess Holle wrote:
> So what is AOP good for? It's a powerful tool for building certain
> types of library/framework capabilities. ...

Just relating a personal experience, I had read various bits on Aspect
Oriented Programming (or aspects in general) but they always seemed to
be vague descriptions - "they are cross cutting concerns". Err, ok, but
like what does that really mean??? I never "got it". So just in case
anyone else is in the same camp of not quite getting the point of
aspects, I thought I would share an example that suddenly made it make
sense to me. If nothing else, this post might give others the enjoyment
of saying "gee this guy is just slow to understand isn't he!" ;-)

I came across a concrete example recently in the Alfresco content
management system. (Not really programming, but it was a concrete
example that made sense to me.) Expressing in programming terms, in
Alfresco you can define a class hierarchy for different document types
(e.g. generic base class that stores an array of bytes representing the
file contents; a subclass say for Office documents with metadata
properties common to Word, Excel, and PowerPoint; then a subclass per
exact file format with additional properties specified to each file type
and maybe saying how to index the file contents appropriately).
Inheritance makes complete sense here. Now for aspects. Within an
Alfresco repository you might want *some* instances of documents also to
be under version control, or record management control. This is not per
document type - it "cuts across" different document types. Similarly
some instances of files maybe under Record Management control (e.g.
"this file cannot be deleted for 5 years"). So in Alfresco you can add
an aspect (in this case "records management") on a per instance basis.
The aspect is not part of the class hierarchy - but it does give the
instance more properties.

I am not saying this is exactly the same as AspectJ - I have never used
AspectJ. I just found it helped me understand terms like "cross cutting
concern" in a much more concrete way. I now at a conceptual level read
"aspect" sort of like "Java interface", but one that can be added to
object instances at run time irrespective of what class they belong to.

Well, I hope the above helps at least one other person out there! It
was a penny dropping moment for myself.

Alan

Jess Holle

unread,
Jul 23, 2009, 2:32:54 AM7/23/09
to java...@googlegroups.com
Having some experience in content management, I'd think that under the covers this would not be done via aspects but rather via mix-in interfaces and/or composition.

Oliver Gierke

unread,
Jul 23, 2009, 2:41:17 AM7/23/09
to The Java Posse
I just heard the comments of the posse and am quite disappointed. Not
because they seem to dislike it (as it's up to everybody to build
one's own opinion) but rather that the argumentatzion was build on a
good bunch of halfknowledge. Here are my points:

1) AOP is a concept. So how can one blame a concept "overkill". This
reminds me of late Pascal an C programmers not grasping object
orientation and claiming that this would be overkill. As already
stated, AOP targets crosscutting concerns that are - and here is the
point - mostly of technical nature not directly related to the
business domain problem you actually have to tackle. So AOP is a mean
to distill problem domain code from the fuzzy technical stuff that
buzzes around in average joe programmer's code. If you just take
exception handling, transaction management, caching and logging/
tracing code out of your legacy code, how much time would you save on
trying to understand what problem this code *actually* solves. Even
more business related tasks, like notifications and so on can be
effectively solved with AOP means. It simply aims to build more
loosely coupled systems.

2) AOP is not widely adopted. Hey guys? Have you used an app server
these days? Almost all app current servers provide technical services
to hosted components by leveraging AOP means. So often times you use
AOP without even noticing it? Which leads me to the next point...

3) Accessability: As AOP is a concept, the question of accessability
is more one of the implementation. As you could have found out there
are several ones. Spring container e.g. uses a proxy based approach
that does not bother you with build time constraints or runtime JVM
option requirements. Use the container and you (as already mentioned)
probably use AOP without even knowing. There are a few other weaving
options available (complie time, runtime...).

4) Fuzzyness because of indirection. Well... how many levels of
indirection do we already have in the Java language? If this counted
as an argument, we'd have to complain about a lot more things. *I* am
really open to take this burden as it allows modularize my
application, make it more extensible and helps distilling the code i
have to write to solve my business problem from the one I have to
write to plumb that stuff together.

5) Annotations replace(?) AOP. I don't know how you got into that but
that was the point that made clear that a little more investigation
would have been good before answering the question. One more time: AOP
is a concept and leverages the notion of pointcuts to define *where*
to apply a specific behaviour. They (in the an example case) can be
formulated onto plain method signatures. That serves point 4, as the
code that gets the advice applied does not know about that fact.
Adressing that problem you typically use annotation *in conjunction*
with AOP to achieve a more declarative style of adding functionality
that is not directly related to the code to the code. @Transactional
or its derivates are the perfect example. So this is not an either/or
but rather a cooperation.

6) Tooling. AJDT is really a helper when it comes to make relations
between advices and their targets visible. You can debug stuff
seamlessly, see, where which advice get's applied and so on. Doesn't
the whole Java space already rely on tooling? Wouldn't any newbie
wonder when its method does not get executed because it was overriden
by someone else? Ahh, we have markers in the IDE... we have
@Override... I think you get my point.

Phew... quite a lot point. I hope you don't get me wrong. It's totally
okay to me for you guys to build opinion different than mine, but you
shouldn't doom something a "tiny magic toy" without deeper knowledge
on it. I guess someone badly informed could argue the same way on
Scala, too: "Whoo... all that scary stuff!" :).

One thing I entirely agree with you that AOP seems to be a Java
related thing due to the limitations of the language. But I doubt that
things are less obscure and fuzzy when implemented in other languages
means (Groovy meta class stuff and so on=.

Regards,
Ollie

Jess Holle

unread,
Jul 23, 2009, 3:14:07 AM7/23/09
to java...@googlegroups.com
I still think AOP as a concept has been driven into containers, libraries, and frameworks where it can be "managed" (and hidden).

Use of something like AspectJ for ordinary development rather than bottled up and fully hidden by a container, library, or framework seems exceedingly rare.  Moreover, use of something like AspectJ for general development (as opposed to runtime ad hoc troubleshooting) seems unworkable.  Needing something like AJDT is a sign of a problem -- especially when this something exists only for 1 IDE and fails utterly for extremely large projects.  [We had one large project that tried to use AspectJ, hit a brick wall of performance, etc, issues, and restarted with custom annotation processors.]

In essence for the general programming public AOP has been replaced by more refined/specialized technologies, e.g. dependency injection, various annotation-based magic, etc.  In cases these are implemented via AOP or byte-code weaving, but the general programming public does not *see* AOP.  That seems a necessary and good thing -- as generalized, unfettered AOP is just too unworkable most especially for Java developers who are used to having explanations for any magic in the source code (not present only when AJDT is used).

--
Jess Holle

P.S. I still do some custom AOP load-time weaving via ASM for a specialized use case -- but there again AspectJ failed in terms of both weaving performance and quality of resulting byte-code, stack traces, etc.

Martin OConnor

unread,
Jul 23, 2009, 7:01:17 AM7/23/09
to The Java Posse
One concrete use of AOP that I've seen that actually makes a lot of
sense is Spring's declarative transactions. They are implemented using
AOP so, for example all of your DAOs can be configured to be
transactional.

On Jul 23, 3:56 am, Jess Holle <je...@ptc.com> wrote:
> 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

Mikael Sundberg

unread,
Jul 23, 2009, 3:01:25 AM7/23/09
to java...@googlegroups.com

Howdy, i use AOP some at work and cant realy see a way to do it any other good way.

for example, management suddenly got the idea that everytime someone saves anything in one application that should be monitored. So we can see who did what. I looked some at annotations and such but that seemd like hard work to annotate al the save methods. So i ended upp with 3 or 4 lines of AOP code and everytime a save or update method is called its also stored who did what. Nothing to remeber when i add new functionality, it just works.

Another time there was suddenly a requirement for logging all method calls and return values, once again... 3-4lines of aop.

how could any of that have been done without AOP?

/Micke

Ruben Reusser

unread,
Jul 23, 2009, 1:29:22 PM7/23/09
to java...@googlegroups.com
hey there

On Thu, Jul 23, 2009 at 12:01 AM, Mikael Sundberg <mikael.s...@gmail.com> wrote:

Another time there was suddenly a requirement for logging all method calls and return values, once again... 3-4lines of aop.

how could any of that have been done without AOP?

Isn't it that most projects just use the ASM library and implement their aspects themselves? If only every method call would be a message and one could listen to messages in a queue and modify the message on the fly...

Ruben

Jess Holle

unread,
Jul 23, 2009, 2:08:59 PM7/23/09
to java...@googlegroups.com
In cases of simple "do this too" code any real possibility of side-effects to the existing code, AOP makes sense.

Having done a lot of monitoring and logging code, I've found that in many cases it involves much more (e.g. examining various existing local variables or interweaving throughout existing method bodies) than what one can reasonably do via AOP.  If you have cases that are simple enough and sufficiently side-effect-free that you don't see a need for those examining the code to see what you're doing, then great, use AOP.

That said, the pain of AspectJ (in terms of its onerous impact on the build process or relatively high penalty for load-time weaving) has turned me off even in these cases -- except for cases of dynamic, ad-hoc addition of extra logging or monitoring in a production system.  Even there one has to be excruciatingly careful with one's aop.xml or you'll grind everything to a halt.

--
Jess Holle

kinko

unread,
Jul 24, 2009, 12:16:42 AM7/24/09
to The Java Posse
On Jul 23, 11:56 am, Jess Holle <je...@ptc.com> wrote:
> 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 :-)

I really didnt agree with the opinions voiced on the adoption, or
rather non adoption of AOP.
Have any of the panel ever used a Framework such as Spring of Guice,
do they actually understand how @Transactional works.
The vast adoption of these frameworks is alone enough to say AOP is a
success.
I think AOP has been a great success in wide range of issues the
require cross cutting concerns, admin, security , tracing ,
transactions etc
Transactional demarkation is not something I would say is 'rare'
either

Liam

Jess Holle

unread,
Jul 24, 2009, 11:48:39 AM7/24/09
to java...@googlegroups.com
kinko wrote:
On Jul 23, 11:56 am, Jess Holle <je...@ptc.com> wrote:
  
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 :-)
    
I really didnt agree with the opinions voiced on the adoption, or
rather non adoption of AOP.
Have any of the panel ever used a Framework such as Spring of Guice,
do they actually understand how @Transactional works.
  
AOP is hugely important as an underlying technology *behind* frameworks.

I see it as nearly dead in terms of direct usage (i.e. not hidden under a framework) by normal developers, though.  It's just too uncontrolled, untraceable, and, in the case of AspectJ, can have a really dramatic impact on build and tooling requirements.

The vast adoption of these frameworks is alone enough to say AOP is a
success.
I think AOP has been a great success in wide range of issues the
require cross cutting concerns, admin, security , tracing ,
transactions etc
Transactional demarkation is not something I would say is 'rare'
either
  
No, but usage of AOP (e.g. AspectJ) directly is rather limited.  For things like transaction demarcation you really want to see an annotation or some such in the source making it clear what sorts of things are going to magically happen -- not have AOP reach in and add behavior without a trace.

--
Jess Holle

Dick Wall

unread,
Jul 24, 2009, 12:03:08 PM7/24/09
to The Java Posse
Hi Liam

Your examples are well taken, I guess I tend to think of using AOP as
the full on cross cutting defining hooks in XML files and so on, and I
have never used that. Indeed in Guice I tend not to use the AOP
features much either (unless you count the basic injection, which I
guess in some senses you could).

I do still stand by my statement about AOP tending to be a Java
language concern though. In something like Scala, I would choose to do
transaction demarcation using closures and a loan pattern, so you
could end up with:

transaction {
....code here....
}

but that is harder to do with Java for sure.

Anyway, I think we did mention that for some people (power users) AOP
is obviously a very good thing, but I don't believe the mainstream
Java development community has adopted the full XML and cross cutting
stuff extensively. Where you get @Transaction for free, that's great,
but perhaps the biggest testament to that is that generally people
don't know they are using AOP to get that feature.

Cheers

Dick

Dick Wall

unread,
Jul 24, 2009, 12:04:09 PM7/24/09
to The Java Posse
What he said :-)

Dick

kinko

unread,
Jul 24, 2009, 8:47:41 PM7/24/09
to The Java Posse
Hi Dick

I suppose you have had different experiences from my work.
I have found AOP a very powerfull paradigm in integrating with alot of
proprietary API's especially todo with entitlements and security.
To beable to simply say @Entitled, rather than the rest of the boiler
plate, user lookups, service calls, is a real blessing.

Agreed closure ideas do also help in these concerns, Spring
demonstrates this kind of, in the best way Java supports currently,
with the template pattern. And dont get me wrong I think Java needs
some kind off closures, the forkjoin examples prove this much alone.
But still I feel the annotation delivery is far more expresive and
concise in these examples. I think also there could be interesting
ideas in concurrency coming from the use of AOP and annotations.

I feel AOP and annotations have the same initial problem to users.
From the offset it is pretty difficult to see the point, but once you
get to grips with them the application domain becomes very broad.
Another example which I have found very usefull is for transient
failures, to beable to mark a method as @Retryable, and not need to
think about the try, catch , backoff etc , is great.

I agree with the point above, yes frameworks will probably be the most
broad usecase, but I also think they have alot of applications to the
general developer. Depends in what domain you are working I feel

Cheers for the interesting podcast

Liam


minuteFForts

unread,
Jul 26, 2009, 4:14:15 PM7/26/09
to The Java Posse
Hello everybody!

I have to say a very good discussion about AOP and its pro and cons!

After some experience I mostly agree with the sceptic view of Jess:
Leave AOP to the frameworkers.

When pondering about the different mindsets and attitudes towards AOP,
I spontaneously wrote this (please do not take too seriously):

Which kind of AOP hater are you? ;-)

To me the AOP antagonists can be divided into three different groups:

1. The Innocent

These are the people who do not see the point in attempting to manage
the complexity of crosscutting concerns. They value the costs and
risks of bloated, repetitive code as non-critical for their project
success. When you have a big team of not so top-notch developers and
you need only to care about short-term performance (say getting out a
first release), this is a perfectly viable strategy (with known
downsides). Of course, many times you find yourself in such a
situation, even if you do care.

And then there is the group of Java developers, who never did anything
else but Java and who still think that for every decently challenging
task on hand you have to develop against at least a dozen wickedly
complex APIs, which you somehow have to repeat in every single
business class. Wonder how much are left of those? Too many, I guess.
- Please, learn a scripting language!

2. The Clever Ones (really!)

The second group is fed up with LazyInitializationException, EJB 2 and
leaving all the fancy stuff to the RubyOnRails kids. They want clean
and simple, but with the complexity there under the hood. They want to
persist, transact, catch, log, notify, … and still have a business
class, which looks like a junior java programmer’s first POJO.

It seems they want to take a shower without getting wet. This sounds
like magic - and it is! Whether it is the doable sort is still wildly
debated. But some progress has been made (in and out the Java
Community) with many seemingly different approaches: code generation,
IOC, Dynamic Proxy, AOP, Meta Programming, Mixin, low-level byte code
enhancement, etc. To me all those approaches have one thing in common:
They attempt to enhance a class or a source base outside of the direct
reach of the (application) developer who wrote that class. They
somehow put in the “magic” without bothering (too much) the poor
bastard who only wanted to write a class which manages taxes. And what
is important, they do it in a transparent way: The app developer can
still come back to his original unbloated class, change this and that
and not have it explode in their faces.

Of course, transparency is relative. Depending on the approach, not
everything might work too smoothly: Debugging, performance, deploying
and too much transparency might all get you in trouble. But the
biggest problem probably is the language Java itself. It is statically
typed. Meaning that with many approaches the very thing we want to
achieve (post-enhancing what must not change) is evil. We want to do
black magic. And many Java developers still think that they would have
to take unbearable risks when loosening up Java’s ability to type
check everything at compile-time. Of course, they already take those
risks everyday (or someone in the background quietly bends the rules
of nature for them).

But if you actually are in group 2, your need is great: You have
accepted to resort to drastic measures. Only, you disagree about the
right kind of drastic. You have good reasons to refrain from AOP:
Tooling, deployment woes, performance issues, lack of transparency,
etc. To me, this is a perfectly acceptable point of view. You have
realized what the problem is, but you just found other remedies more
suitable to your tasks. Let us swap our findings and see what gives.

3. Those who always knew (aka The Concerned)

The third group has recognized the worries that drive group 2, went
into the laboratory, fumbled with the mighty mojo and got themselves
badly burned. Or more likely, sent their minions into the lab and
simply waited for the cry. The deficiencies that concepts like AOP or
Meta Programming attempt to overcome - sort of the sonic barrier of
invariant source code – should not be easily tempered with. But then
again quite a lot of developers should be stripped of the right to use
inheritance. They simply have not understood when not to use it.

Thus, yes, apply with caution. Know the risks. Search for the big
wins.

Or come up with a better way!


Best,
Achim.

kinko

unread,
Jul 27, 2009, 6:14:18 PM7/27/09
to The Java Posse
I really think it depends what domain you are in.
From my experience it can be exploited it in a number of areas outside
of frameworks, see my reply to Dick
Reply all
Reply to author
Forward
0 new messages