Raise of hands (virtually): How many here use AOP?

[Danno]

Just curious about all programmers here: How many of you use Aspect
Oriented Programming? If you do, do you use AspectJ, JBoss AOP, or
something else?

 

[Mark Thomas]

Just curious about all programmers here: How many of you use Aspect
Oriented Programming? If you do, do you use AspectJ, JBoss AOP, or
something else?

I use AspectJ

Mark

 

[Darryl L. Pierce]

Just curious about all programmers here: How many of you use Aspect
Oriented Programming? If you do, do you use AspectJ, JBoss AOP, or
something else?

We're using AOP in my current project at work.

 

[josh.s17]

Can anyone suggest a good introduction to Aspect
Oriented Programming?

 

[Oliver Wong]

Just curious about all programmers here: How many of you use Aspect
Oriented Programming? If you do, do you use AspectJ, JBoss AOP, or
something else?

Playing around with AspectJ for one of the projects at work here.

- Oliver

 

[Chris Lamb]

Can anyone suggest a good introduction to Aspect
Oriented Programming?

I found the Laddad book (AspectJ in Action) quite informative from
a beginner & AspectJ perspective.

Chris

 

[ducnbyu]

I never even heard of AOP before reading this thread. Man! This means
I don't have to bastardize an elegant solution with security and error
checking anymore! I can bask in my nice pretty code over here and keep
all the ugly code in a cage over there... Though at first glance it
seems like the crosscutting means security and error code have
potential to become elegant too. I'll see how that goes soon.

I guess since I'm using Eclipse I'll be working in AspectJ soon.

I'm just starting to read up. I didn't quite understand the difference
between these two examples from Eclipse's AspectJ Intro.

http://www.eclipse.org/aspectj/doc/released/progguide/starting-aspectj.html

after(FigureElement fe, int x, int y) returning:
...SomePointcut... {
System.out.println(fe + " moved to (" + x + ", " + y + ")");
}

after(FigureElement fe, int x, int y) returning:
call(void FigureElement.setXY(int, int))
&& target(fe)
&& args(x, y) {
System.out.println(fe + " moved to (" + x + ", " + y + ")");
}

Maybe I need to reread the accompanying text 3 or 4 dozen times. Does
anyone want to shed some light? I guess I don't understand what this,
target and args primitive pointcuts buy you that the first example
doesn't already have.

Thanks Danno for posting the poll.

 

[robert]

Danno escreveu:

Just curious about all programmers here: How many of you use Aspect
Oriented Programming? If you do, do you use AspectJ, JBoss AOP, or
something else?

I use the spring framework.

Robert
http://www.braziloutsource.com/

 

[Chris Smith]

I never even heard of AOP before reading this thread. Man! This means
I don't have to bastardize an elegant solution with security and error
checking anymore! I can bask in my nice pretty code over here and keep
all the ugly code in a cage over there... Though at first glance it
seems like the crosscutting means security and error code have
potential to become elegant too. I'll see how that goes soon.

See http://riters.com/JINX/index.cgi/AOP_20Considered_20Harmful

(I wrote it, based on a newsgroup post from some time ago... so it's no
great authority or anything. Just some thoughts to keep in mind before
you start AOP for the first time.)

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Danno]

Ooops, I totally forgot to include Spring. thanks, Robert

 

[Danno]

Interesting read. thanks for posting Chris

 

[ducnbyu]

See http://riters.com/JINX/index.cgi/AOP_20Considered_20Harmful

Thanks for the early reality check. As an AOP neophyte, therefore
taken with a grain of salt, I still like the idea of removing security
and error checking from the problem solution. So you have the elegant
solution, the elegant error checking and elegant security all sitting
in their own planes of existence. But point taken about breaking
encapsulation. And also about not seeing all code that is responsible
for the end result behavior within the original class. Your caution is
well taken.

I'm wondering if there is some suitable documentation technique that
minimizes some of the pitfalls mentioned in your article. Anyone have
any thoughts on that?

 

[ducnbyu]

I'm still reading, and I came across a pro-AOP article that reminds of
an original goal of OOP:

Reusability.

It looks like the benefits of AOP can be worth the trouble when we can
keep non-core business out of a class. A "reuser" has the choice to
take the Aspect or not without having to clone or extend and override
the class to unweave the unwanted code. So far it doesn't seem "AOP
Considered Harmful" any more than heartburn considered harmful versus
the benefits a medication will offer. Overdosing on medication or AOP
is user error, it doesn't mean they are poison.

BTW I tried to follow the links to the extremely worrying examples on
the Internet, but I was lead to a contentless page. Do you still have
access to the correct links?

 

[jamesahart79]

I've seen too many subtle errors in code where everything was cleanly
laid out and there was a clear mapping between lines of code and
behavior to ever trust an idea which *invisibly* changes code. The
potential bugs waiting to happen boggle the mind. And happen they
will.

I like the idea of cross-cutting concerns and eliminating them. I know
of a few places where I would just love to be able to do it. I will
never do it unless the system requires me to place annotations above
the affected code before the code gets modified. And I will never in
my lifetime trust a system which uses pattern-matching techniques to
place invisible code changes. I've seen pattern-matching fail far too
often to fall for that.

On the other hand, with sufficiently powerful annotations and tools, I
will doubtless eventually use some form of AOP.

 

[ducnbyu]

On the other hand, with sufficiently powerful annotations and tools, I
will doubtless eventually use some form of AOP.

I am still researching mind you, but I ran across this blurb in the
Eclipse AspectJ introduction

http://www.eclipse.org/aspectj/doc/next/progguide/starting-production.html

"The IDE support included with AspectJ automatically reminds the
programmer that this aspect advises each of the methods involved. The
IDE support also provides commands to jump to the advice from the
method and vice-versa."

Wouldn't this be sufficient? No matter how complicated your pattern
you'd be able to see which methods are affected by a given Aspect and
which Aspects are involved in a given method and you can refer back and
forth between them. (The way I read the blurb.)

 

[Chris Smith]

http://www.eclipse.org/aspectj/doc/next/progguide/starting-production.html

"The IDE support included with AspectJ automatically reminds the
programmer that this aspect advises each of the methods involved. The
IDE support also provides commands to jump to the advice from the
method and vice-versa."

Wouldn't this be sufficient? No matter how complicated your pattern
you'd be able to see which methods are affected by a given Aspect and
which Aspects are involved in a given method and you can refer back and
forth between them. (The way I read the blurb.)

Sufficient for what?

First and foremost, this is only sufficient if you plan to do all of
your development in Eclipse with the IDE support for AspectJ enabled.
Pity the fool who uses JCreator. Incidentally, I do develop pretty much
all of my code in Eclipse, except that about a year ago I had to make
some changes to a production system via a telnet window with vi while I
was about 100 miles from my laptop.

More to the point, the problems with AOP (outside of using annotations)
represent a flaw in the way the language is used. It is an abuse of the
language. Even if it's possible to make it work by detecting the bugs a
little earlier (which is essentially what an IDE plugin does), it's
still bad programming. This kind of thing may have been necessary until
annotations were added to the language... but it's now completely
unnecessary.

I am waiting for the moment when that becomes more widespread knowledge.
The result will be not only a safer way of accomplishing tasks like
transaction handling, but also a simpler and more elegant implementation
of aspect-oriented programming, because it will not be necessary to
match methods based on the name or the signature or something like that.
In the interim, it's possible to do this using AspectJ, and just
remaining careful about using the obsolete features that let you define
non-annotation based pointcuts.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Thanks for the early reality check. As an AOP neophyte, therefore
taken with a grain of salt, I still like the idea of removing security
and error checking from the problem solution. So you have the elegant
solution, the elegant error checking and elegant security all sitting
in their own planes of existence. But point taken about breaking
encapsulation. And also about not seeing all code that is responsible
for the end result behavior within the original class. Your caution is
well taken.

The point was not to completely avoid AOP. In fact, AOP has a fair
number of benefits. It's just important to use it well. I don't think
documentation is the answer. AspectJ version 5 allows you to define
pointcuts based on Java 1.5 annotations. I'd advise that you ONLY
define pointcuts in that way. Then there's really nothing left to
complain about.

If you define pointcuts on the basis of something other than
annotations, then documentation would still help... but it can never
really be good enough.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Oliver Wong]

This kind of thing [AOP?]
may have been necessary until
annotations were added to the language... but it's now completely
unnecessary.

Just checking here: are you saying that it's possible to do what one
"normally does in AspectJ" using annotations? Or are you saying that using
non-annotation pointcuts were nescessary, but now that we have annotations,
they are not?

- Oliver

 

[Chris Smith]

Just checking here: are you saying that it's possible to do what one
"normally does in AspectJ" using annotations? Or are you saying that using
non-annotation pointcuts were nescessary, but now that we have annotations,
they are not?

The latter. Obviously, annotations alone do nothing. However, in
conjunction with AspectJ, they help avoid the serious drawbacks of AOP.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[ducnbyu]

Sufficient for what?

Was asking James the question: is Eclipse's implementation
"sufficiently powerful" for him.

First and foremost, this is only sufficient if you plan to do all of
your development in Eclipse with the IDE support for AspectJ enabled.

That's what I was asking, thanks.

Pity the fool who uses JCreator. Incidentally, I do develop pretty much
all of my code in Eclipse, except that about a year ago I had to make
some changes to a production system via a telnet window with vi while I
was about 100 miles from my laptop.

You wouldn't restrict your development to some extreme lowest common
denominator, i.e. telnet, would you? I mean even so, in that extreme
case you'd make the fix, racking your brain with limited visibility,
and then go back to your laptop as soon as possible and check
everything out. I guess I'm not following. You acknowledge that
Eclipse IDE with AspectJ enabled is sufficient if you do all your
development in Eclipse, which you do. Yet you still don't want to reap
the benefits of AOP.

More to the point, the problems with AOP (outside of using annotations)

I have to admit I haven't yet gotten to the part in my reasearch where
AOP using annotations is an improvement so please bare with me. And I
take your word for it.

represent a flaw in the way the language is used. It is an abuse of the
language.

Yes, peeling a layer of skin off of encapsulation, but in a controlled
way. Coding "cross-cutting concerns" into each affected class is an
abuse of OOP that creates maintenance problems. Lets say you did, code
a cross-cutting concern into, say, 35 different classes pretty much all
the same code woven into those classes where appropriate. You already
used your inheritance card on another concept related to core
functions. And another developer comes in and has to code a new
requirement into the cross-cutting concern. How does he recognize:

1) that the concern is cross-cutting.
2) which code woven into the classes involves the concern without
disturbing the core functionality of the class
3) which classes have the concern's code woven in (how does he know he
got them all)

Or needs to code a new requirement into the core functionality of the
class how do you ensure:

4) he does not diverge the cross-cutting code so that it is less
recognizable than in the 34 other classes?
5) over time with maintenance (new requirements etc.) all of the
cross-cutting code in all 35 classes do not diverge and becomes
unrecognizable as related.
6) over time all of the cross-cutting code behaves the same way.

Do you feel that the above error prone process is the lesser of the
evils here?

Even if it's possible to make it work by detecting the bugs a
little earlier (which is essentially what an IDE plugin does), it's
still bad programming.

Even meeting all of your requirements it's still bad? IMHO bad code is
the result of some combination of laziness, lack of skill, over
engineering and showing off. How is the intentional use of a tool that
provides real, recognizable benefits, for some trade-offs of course,
bad programming? I asked in so many words in a prior post: Why are
these trade-offs not worth the benefits?

This kind of thing may have been necessary until
annotations were added to the language... but it's now completely
unnecessary.

I am waiting for the moment when that becomes more widespread knowledge.
The result will be not only a safer way of accomplishing tasks like
transaction handling, but also a simpler and more elegant implementation
of aspect-oriented programming, because it will not be necessary to
match methods based on the name or the signature or something like that.
In the interim, it's possible to do this using AspectJ, and just
remaining careful about using the obsolete features that let you define
non-annotation based pointcuts.

Why do you need to wait for others to know what you know? If the tools
already (seem to) support what you would like them do what's stopping
you from using them? Are you talking about your peers in your
organization? If so, are they using Eclipse as well, can you bring
them up to speed and catch unapproved techniques in peer reviews?

Thanks for the dialog, it is thought provoking.