RE: [aspectj-users] Philosophical Questions

["Adrian Colyer" <adrian_colyer@xxxxxxxxxx>]

I wanted to jump in on this one too
as its a topic that's been on my mind these last few days. Here's how I
see it...

When anyone first comes to AOP, the
examples they see and the kind of concerns that they deal with tend to
be very "orthogonal" to the core application they're working
on (or "non-functional" if you like that term). I'm talking about
the classic things like tracing and logging and error handling etc.. In
the AspectJ tutorial we sometimes call them "auxiliary" aspects.
With those kinds of aspects in mind, then a "pure" Java plus
XML approach has a certain appeal - the aspects are not critical to the
core application, and "configuring" them via XML does not severely
impact your understanding of the program. In the J2EE / middleware community
which is very used to filters, interceptors, deployment descriptors etc
this will feel like a very natural thing to do.

The problem comes when you get beyond
the "oo-application-with-a-few-auxiliary-aspects-bolted-on-the-side"
phase. When you start to do aspect-oriented programming with core aspects
as a natural part of your application design, then all of a sudden the
framework + XML approach looks a whole lot less attractive. You really
do want a solution that works as part of the programming language, with
your development tools, expressing your intent as clearly as possible in
the source code. AspectJ lets you do that, and allows you to think of aspects
as first class entities in the language - this is so powerful. I don't
want to have to parse side XML files and perform a "weave" in
my head in order to figure out what my program means. Personally, I'll
even use an inner aspect inside a single class to handle a policy that
cuts across the methods of that class (acquiring and releasing connections
in a db access class for example) where it makes the intent clearer. You
just wouldn't do that with run-time interceptors and XML configuration.

So, I think that these frameworks have
an appeal for folks looking at auxiliary aspects. If that's all you want,
then some of the frameworks are very good examples of doing that. I also
believe AspectJ is very good at handling these kinds of concerns btw..
But if you want an approach that takes you into aspect-oriented programming,
that grows with you as your confidence and understanding grows, and that
gives you a uniform way of handling aspects from development time aspects
right through to core function, then you need AspectJ. And once you've
gone beyond auxiliary aspects, and tasted what it's like to really explore
aop, you'll never look back :)

-- Adrian
Adrian_Colyer@xxxxxxxxxx

"Gregor Kiczales" <gregor@xxxxxxxxx> Sent by: aspectj-users-admin@xxxxxxxxxxx 07/07/2003 16:59 Please respond to aspectj-users

To:        <aspectj-users@xxxxxxxxxxx>         cc:                 Subject:        RE: [aspectj-users] Philosophical Questions

I'm really glad you sent this
message.  This reply is about a general point, I'll tackle the specific
points later today.
 
The flurry of alternative AOP
frameworks is clearly a good thing. It shows that AOP has moved from the
invention phase to the first innovation phase. More people are looking
at the technology, in a solution oriented approach, to see what it can
do for them.This will be an exciting time.
 
But while I think lots of innovation
is great, I worry that these systems may cause people who are just starting
to learn about AOP to reach some false conclusions.  Specifically:
 
 - because these systems
have no IDE support, they run the risk of stoking the false argument that
AO programs are hard to understand or debug. With AspectJ, a simple ajdt
demo is enough to show that these problems are solved.
 
 - because these systems
are dynamically typed, they run the risk of convincing people that AOP
is inefficient and also that debugging will be more difficult with AOP.
 
 - because these systems
don't necessarily have orthogonal join point models, they may seem simpler,
but run the risk of making larger AOP programs more complex to write and/or
understand.
 
 - because most of these
systems are a subset of AOP, they run the risk of causing people outside
the community to complain that "the AOP people are talking a lot about
a very little". For example, many people look at these systems and
conclude that AOP is just interception -- they miss the whole point about
how pointcuts allow building up crosscutting structure.
 
 - because of the claims
people make about these systems, they run the risk of causing people to
believe that no one is doing any commercial AOP yet, and that AspectJ doesn't
work. Many AOP developers would be better served, IMHO, to use AspectJ
with its much higher degree of engineering, documentation and support.
 
Don't get me wrong, I strongly
believe this round of innovation should continue, it is a great thing.
I am personally enjoying discussions with some of the authors of these
new systems as to elements of their design.
 
But I wish the voice of AspectJ
experience was more represented in this round of debate about using AOP
in practice.  For example this idea that AspectJ is too powerful needs
some debunking. Its trivial to subset AspectJ and still end up with an
orthogonal, type-safe, efficient, system that has 5 years of user experience
with it. If size is the issue, that is probably a better way to go.
 
So...
 
I'd really like to encourage AspectJ
users who have running code and experience to speak up more on the many
blogs that are hosting most of this round of AOP discussion. Please speak
up! (Its sort of frustrating that all this happens in individual blogs
rather than discuss@xxxxxxxx,
but that's a whole other issue!)
-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-admin@xxxxxxxxxxx]
On Behalf Of Merrick Schincariol
Sent: Saturday, July 05, 2003 8:03 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Philosophical Questions

Having just got back from TheServerSide Symposium in Boston, I can report that AOP was definitely the talk of the conference. What was surprising to me, however, was the lack of focus on AspectJ. Most comments were of the form "it's too powerful for most developers" or that the special compiler makes it difficult to sell in most organizations. Instead, most of the talks focused on newer "pure Java" AOP frameworks.

I personally find AspectJ to be a well designed implementation of AOP concepts. On my weblog (http://www.freeroller.net/page/mschinc), I've been documenting my own exploration of the capabilities that AspectJ provides. Looking closer at "pure Java" approaches like AspectWerkz (http://aspectwerkz.codehaus.org/) something has been bothering me, but I haven't been able to put my finger on it. I'd like to put a couple of questions out to the list and see where your thoughts are on the subject.

1) Can Aspects themselves be broken down into smaller sub-components?

Most of the Java AOP frameworks break out aspects into a number of different pieces. For example, you implement your advice as one Java class, your introductions as another and then define (usually using XML) the pointcuts and the relationships between the components. So one Aspect could actually require many files to implement and define. Does the complexity of this approach interfere with the AOP philosophy? My fear is that when the implementation requirements are complex, from a language point of view, you start to lose track of the problem you are actually trying to solve.

As an aside, I think the AspectWerkz design for advice is broken. Because each type of advice is a class (pre, post and around) and each advice class extends a pre-existing class, you can't share any information between different types of advice on the same pointcut.

2) Can pointcuts be modeled separately from advice?

This follows on the above point, but it's one that I find a little odd. Most (all?) of the pure Java approaches define their pointcuts in one file and their advice in another. Presumably this means that advice can be reused across multiple different aspect definitions. From a philosophical point of view, can advice be modeled truly independently from pointcuts? I would think that certain types of advice, particularly when dealing with cflow and other advanced join points, really require the pointcut definition to be present in order to make sense.

3) What role, if any, should metadata play in AOP?

I know Gregor has commented on the use of metadata a couple of times, but the JBoss group is charging ahead with their "AOP" product which encourages developers to use class metadata to load library aspects. This strikes me as wrong in many ways, but the message that is reaching the development community is that interceptors and metadata are all you need to do AOP. Is this just a function of what's easy to implement, or are people really having trouble grasping the concepts?

I'm looking forward to hearing your thoughts.

Cheers,

Merrick