My Photo

August 2007

Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

« AOSD 2005 BOFs | Main | Load Time Weaving with AspectJ 5 »

May 04, 2005



Industry analysts have only started noticing because JBoss just started paying them to notice. Read about the real facts at

Ron Bodkin

I don't think that's the case because:
1) Richard Monson-Haefal told me the AspectJ/AspectWerkz merger triggered the Burton Group's interest. The very blog you cited speaks favorably of Anne Thomas Manes, who is Richard's manager, which is ironic given your reference. I think they are both great.
2) JBoss has been pulling back from promoting AOP. Their message is now annotations for ease of development. They do still say AOP for extensibility, but not to their customers (more for ISV's)...
3) Gartner started covering AOSD in 2003 which would have been very early for JBoss to sponsor analyst research.
4) It's certainly not likely that JBoss paid for the report Forrester delivered...

Carl Zetie

Thanks for the reference to my report on AOP. Yes, it only *formally* cited one research paper -- the one that I found most efficiently highlighted specific technical issues with AOP. But of course that wasn't my only source. I read numerous blogs and online reports, both pro and anti. I spoke with programmers, managers and consultants, both pro and anti. And I took the trouble to learn AspectJ's syntax for myself so I could properly understand whether the criticisms of its lack of transparency were valid.

I'm happy to send a copy of the report -- as well as more detailed description of my methodology and sources -- to anybody who wants to email me. Then you can judge for yourselves whether I make valid points. If you still disagree with me then fine -- but at least you'll be disagreeing with what I wrote, not hearsay.

As for experience? I wrote my first professional program in 1982, on a distributed, real time 8 bit microprocessor system. (In them days we had code our own cross page jumps and considered ourselves lucky we weren't using paper tape.) Yes, I've written actual large, complex, multithreaded programs in real languages. Since then I've seen a few programming ideas come and go...

For the record I'm a big fan of Spring (and lightweight frameworks in general) and a booster of Eclipse (under whose auspices AspectJ/Aspectwerks now falls of course). Being the "contrarian" that I am, I still feel free to critique AOP.

Also, I don't know when Richard's (an analyst whose work I respect, even if we disagree about the readiness of AOP for mainstream adoption) report was written, but I've been speaking out about AOP for several months, as anybody who heard me speak at EclipseCon back in February can attest. Like Richard, I was prompted to write (rather than speak) about it by the merger. I notice that the report that agrees with your views is "carefully researched in-depth analysis" while the one that disagrees is allegedly shallow! You might also want to know that the response from our clients has been overwhelmingly positive, along the lines of "thank you for providing the support I needed to argue against AOP internally". If this is a backlash, its a pretty strong one.

It is surprising me that a blog author would write something extremely negative about an analyst on the basis of hearsay, without bothering to contact the analyst in question to try to verify the information (I am VERY easy to track down).

Unfortunately, it no longer surprises me that whenever an analyst writes something they disagree with, a blogger or a commenter will claim that they *must* have been paid to say that. (And Ron, I have to say that IMO its a little bit weasely to say in your post "It is interesting to speculate if there are other motives involved", then leap to defend Forrester from accusations of taking JBoss' money in a comment. Actually, I think its pretty poor in general to speculate about the motives of somebody you've never met or exchanged views with and only know about secondhand under any circumstances). Think about it for a moment: two of the biggest proponents of AOP are BEA and IBM. What sense would it make for *any* analyst firm to write something to please JBoss or Sun while upsetting IBM and BEA? Or vice versa? It simply doesn't stand up to logical scrutiny. The *only* approach that is viable for a reputable analyst firm is to be as scrupulously independent of vendor influence as humanly possible. "The real facts", indeed.

Ron Bodkin

1. I followed up on Carl's posting with the following email:

Hi Carl,

I wanted to follow up on your comment to my blog entry. In fact, I did try to track you down but wasn’t able to find your email address prior to your comment. As a former member of the AspectJ team at PARC who is using the technology as a foundation for a new business, I would like a chance to present the case for AOP to you. At my previous company, C-bridge, we subscribed to Giga research and I always liked the work you have done in past. I presented a tutorial on AOP at EclipseCon and am sorry we didn’t see each other at one of our talks (I wasn’t able to come to your talk as I’d hoped).

Some specific points in regards to your message:

- I would appreciate a chance to read your report first hand and to have permission to share it with a few others ...

- I’d also like to understand your methodology and sources. In particular, I’d like to know which experts you spoke to, because none of the experts I have contacted say they spoke to you. That's part of why this report created so much buzz in AO-land. For example, you didn’t speak with Gregor Kiczales, Adrian Colyer, Jonas Boner, other members of the AspectJ team, Ramnivas Laddad, or Nicholas Lesiecki.

- It’s worth noting that the “research paper” you cited isn’t really a research paper. It wasn't reviewed or otherwise subjected to outside scrutiny. Maximillian Stoerzer wrote “as one of the authors of the referenced paper, just a short note: This paper was written for a panel discussion, and indeed intended to be provocative.” He also said you hadn’t contacted him either.

My questions about motivation came about precisely because I’ve found the work you’ve done in past to be good. Given the evidence that you didn’t seek out the input of experts, and given the summaries of your arguments I heard from those who did have access, I wondered whether another motivation was at work. I freely admitted that this was just speculation; I certainly never said it “must” have been paid for. From your description, it now sounds to me more like you are in the camp of those who are uncomfortable upon first exposure to the concept of AOP. In particular, if an analyst carefully researched something I believe in and came out against it, I would certainly try to persuade them otherwise but wouldn’t question their motives. It would be great to have a chance to present the case for AOP to you directly.

It is interesting to me that Spring uses AOP significantly and that Rod is a proponent. Or is that the genesis of your admission that AOP is possibly useful for framework builders?

I’m not at all surprised that people who don’t like AOP are pleased to have an analyst report that supports their view. Since the beginning, many people have disliked AOP. Many of those are based on misconceptions about what the technology really is. But not all. People always like to have analysts reports that support their position. Reports were sold saying that OOP would never work. As well as reports that over-hyped OOP. And reports that came down in the middle. Given the successes that have been achieved in enterprise development, and the growing popularity (e.g., 15,000 AspectJ downloads last week), there is also real momentum for the technology.

I’m sure that you have developed systems in past, but that isn’t the same thing as having experience using AOP to do so. This isn’t a criticism of you as an analyst since analysts don’t usually develop systems (while working as analysts). However, the bulk of the criticisms I’ve seen about AOP from people who develop software for a living comes from those who haven’t tried it.

I won’t delve further into the question about analyst motives in general. I agree that reputable analysts should not be influenced by their clients. Unfortunately there are too many counterexamples, and one can’t just assume analysts are unbiased. Where does your quotation “the real facts” come from?

2. To which Carl responded:
Thanks for your long message. Below I've forwarded the response I sent earlier to Mik, whom I'm certain you know, and I've copied him here so that you each know what I've said to the other...

I've also attached a second piece I hope you'll find interesting (agree or disagree) which provides some context for my current thinking about enterprise application development in general, and my perception of a need for a return to simplicity. Intriguingly, as I read the arguments pro and con AOP, its interesting to see both sides claiming the high ground of simplicity in support of their positions.

No, I didn't speak directly to the AspectJ experts that you cite -- but I'm happy to do so if you want to educate me beyond what I have learned through my own efforts. Frankly, listening to people who disagree with me is invariably more useful than having my existing views bolstered.

As I said in my post I spoke to developers, managers and consultants and read widely, including numerous pro-AOP articles, columns, the bits of "Eclipse AspectJ" (by Colyer, Clement, Harley & Webster) that I understood as a non-professional OO programmer, etc., some of them by those experts. (Somebody who appeared quite expert in the topic did "corner" me in an elevator at EclipseCon to disagree with my AOP comments, unfortunately I didn't get his name -- my bad.) I felt I had a good enough grasp of the arguments on both sides to write my piece, but I'm ALWAYS willing to listen to additional viewpoints -- that's my job (and not just because you and Mik said nice things about my earlier work.) If you persuade me I'm wrong then I get to write a follow up piece... Incidentally, one thing I have encountered since writing my piece is a number of people who advocate what I might call "pragmatic AOP": they fully support AOP, but acknowledge the difficulties in using it effectively and (often) the need for better tools to make the effects of aspects more visible.

By the way, when I spoke about the dangers of AOP at EclipseCon, I was surprised to get a spontaneous ripple of applause from the audience -- nothing else I said that day generated such a reaction, and given the number of pro-AOP columns out there I was more expecting to get booed than cheered -- so clearly there is a lot of concern about AOP, as well as the momentum you cite. In fact, if there wasn't such significant momentum, I wouldn't have felt the need to raise a warning flag.

>It is interesting to me that Spring uses AOP significantly and that Rod

>is a proponent. Or is that the genesis of your admission that AOP is
>useful for framework builders?

I assume we're talking about Rod Johnson? To a great extent, yes. I spoke to Rod recently (not on this topic), subsequently learned about his use of AOP in Spring, and decided that if Rod saw something in it, it couldn't be all bad. I believe that in the hands of somebody of his skill level it is a powerful addition to the arsenal. Also in the context of simplifying an IoC container it's a valuable technique. It's the rest of us I'm worried about!

>I'm not at all surprised that people who don't like AOP are pleased to
>have an analyst report that supports their view.

With the report in hand, you'll be able to judge for yourself whether what I say and what people say I say are one and the same. On rereading my own words, I'm not even sure it's as negative as you may have been lead to believe (other than the title:
some people may not have recognized the reference and taken it too literally...). I like to think its more cautionary than damning. Of course, YMMV :-)

>I'm sure that you have developed systems in past, but that isn't the
>same thing as having experience using AOP to do so. This isn't a
>criticism of you as an analyst since analysts don't usually develop

I apologize if I misinterpreted that comment -- usually when I see something like that, it is from somebody who assumes that an analyst (or journalist or columnist or ...) has no *prior* real-world experience, rather than specific current experience.


>Where does your quotation "the real facts" come from?

It's an ironic reference to the first comment about your blog entry from "cindi" who refers to her Jboss conspiracy theory in those words.

Again, if you want to talk about anything that's in the report, or even just want to brief me on the progress and plans of AspectJ/AspectWerkz, I'm always willing to listen. I'd even be happy to meet in person...

Best regards,

P.s. for the record, I still maintain that Smalltalk is a superior language to Java ;-)

3. I then replied:

Hi Carl,

Thanks for your reply. I ... would like to take you up on your offer to meet the week of the 23rd...

I read your report on AOP and look forward to talking more about some of the specifics. I have included some thoughts below and look forward to discussing it more in person.

Also, I plan to post my email comments to my blog...

- I agree with the importance of simplicity in development. I agree about both sides claiming the high ground here. Any kind of new modularity technology adds some complexity to the base model, but if it is addressing a sufficient important problem, it will result in a net simplification.
I think that any argument against AOP needs to deal with the reality of the costs of not modularizing crosscutting concerns, and the pain of the extra-OO methods that are routinely used (code gen, annotations, interception, frameworks, etc.). I think AOP is the simplified, safe, base-level version of metaprogramming, which is the GOTO-like powerful but unmaintainable way of modularizing crosscutting. I have included a few paragraphs I wrote previously about this below.

- Modularizing crosscutting concerns localizes them so you can actually see a succinct description of a policy, rather than just the scattered manifestation. In real systems, for problems like error handling, monitoring, tracing, and transaction management this is significant. With good tools support (both static visualization of the concern and effective debugging and tracing), you can also see and understand how they apply in individual cases.

- For a number of examples of other uses of AOP see for example . For example, consider error handling and also the business-level aspects for metering and account suspension.
In the Spring framework (and elsewhere), aspects are used to provide transaction management, association of long-lived persistent transactions ("sessions") with UI requests, concurrency management, performance monitoring, associating user transactions with UI requests, remote proxies, event publication, and security. There are also good examples of more advanced uses of aspects by JBoss, in the aTrack open source sample project, AspectJ in Action, Eclipse AspectJ, and Adrian Colyer's blog (to name a few).
I don't think the cautious assessment of this report accurately accounts for the strong endorsement and good results achieved by projects that are using the technology.
I see in this a natural analogy of OOP: for a long time advocates of OO used animals and vehicles for their examples, the main uses were horizontal and framework-oriented (notably for GUIs) and critics questioned whether there were any business objects. It takes familiarity with a domain to present realistic examples of use, especially for something as foundational as new modularity technology.

- I grant that AOP is new, it isn't simple, and it requires some real changes in thinking. I think this is just like OO. I think the key thing is to start with good people and to adopt incrementally rather than a high risk big bang approach.

- I agree that AOP implementations for a single language aren't sufficient; crosscutting often applies to many platforms and languages. That, to me, argues for extending the implementations. I wrote about this and on specialized competitors to AOP in a workshop paper I wrote in 2003:

On the understandability impact of AOP:
First off, I'd say that the best tool for understanding a system as a whole is a good design. AOP improves the modularity and supports traceable implementations, making it easier to understand without tools support. An overly complicated OO system can be effectively impossible to reason about, too.

I question the notion that one can just read the code of an OO system and understand what will happen, in practice. Without tools support, finding the possible subclasses or implementers of something is quite difficult, so knowing what actual implementation code will execute is hard. The idea of looking at your code breaks down on the kind of real (large) systems where modularity most matters. Of course for systems that might be extended by 3rd parties, it's not possible if you don't have their extensions.

And of course, identifying the possible implementations that might get assigned to a given field can require reading all the code (possibly including XML configuration files). In the case of worker objects like Runnable or Action, in practice you often can't reasonably figure out what will execute by static analysis either.

Indeed, having good tools to see dynamic behavior is often a requirement to understand real code. A good debugger is helpful for this, and, in fact, AOP makes it easier to trace code (even incomprehensible pure OO code) to understand what's happening.

I'd also note that, in practice, large projects use all kinds of special-case obscure artifacts to address crosscutting, that are also hard to follow without tools support, but (to my knowledge), don't offer good tools support either, e.g.,

- dynamic proxies (either created by the JDK or using bytecode libraries like ASM)
- code generators like Xdoclet (sure you can read the _generated_ code, but how do you trace it back to the sources?)
- execution "containers" (e.g., Servlet and EJB)

You might argue that these aren't OO, but any real critique of AOP needs to address the shortcomings that motivated such alternatives.

4. To which Carl replied:
Thanks for the long note, I will reply only with a very short one for now as it's a Sunday morning, four quick thoughts:

-- Let me know when your blog comment is up as I will almost certainly want to comment! You are welcome to quote from my side of the exchange or from my report IF I can have a chance to preview it ... I will also be blogging this discussion myself. Alas, our management is making our blogs available only to clients to read or comment for the time being, but I am happy to send you a preview to ensure that I am fairly representing your side of the argument...

-- My concerns about AOP really boil down to a superficial one and a profound one. The superficial one relates to visibility, debugging, etc.
-- the kind of things that tools will address over time, but which I don't think are sufficiently there yet. And in fact, Eclipse is probably the ideal tooling arena in which to address those concerns. The profound one is the discomfort I feel with any mechanism that allows the aspect code to modify the context of execution of the original method code (or even prevent it from executing at all). To me that seems to violate the spirit of encapsulation. I think I would feel a lot more comfortable with a version of AOP that guaranteed to leave the original code inviolate (i.e. aspect-enhanced code might do more than the method author asked, but never less).

-- The long list of Spring uses of AOP you mention: to what extent can the typical developer ignore this and simply write his or her POJOs, leaving Rod to take advantage of AOP to implement the IoC container most effectively? To me, the latter is an appropriate use of AOP, a powerful tool in the hands of an expert programmer, that (largely) invisibly simplifies the world that the average IT programmer sees.

-- I understand your historical analogy to OOP. When I first encountered OOP my immediate reaction was one of excitement and recognition that this was a powerful tool and a profound step forward in programming. The more I learned about OO, the more I thought: this is exactly the way I have always *tried* to program, but never had the language constructs to enforce. (I also recall sitting in training classes listening to other people ask questions like "How is this different from COBOL copybooks?") I don't get that same sense about AOP -- and I hope it isn't just because I'm 15 years older and crustier...

Best regards,

5. To which I replied:
- I'd certainly welcome the chance to review and comment on your blog entry.
- I agree with your superficial concern and that the tooling is catching up. In part, because Java has such amazing tools available, any extension to the language or platform has a real challenge to keep up. We've come a long way from 1996, when Grady Booch said "As evolution goes, Java development tools are still at the level of banging rocks together."
- The more profound issue is certainly whether adding aspects to modularize crosscutting concerns is an improvement. It violates the traditional definitions of encapsulation, but mainly because they were failing in the face of some significant problems. I came to AOP from experience trying to get projects to use frameworks to address these kinds of problems, and was excited that AOP is more elegant, easier to use, and less invasive. I also saw in it the ability to modularize things that previously were boilerplate or had a coherent design (e.g., security) but no traceability in the implementation.
- It's certainly true that the way Spring (and JBoss) use AOP, framework users can simply add annotations to code and framework aspects interact. In both cases, a developer can also write pointcuts to use AOP directly.
- I believe that the same set of developers who learned to use objects effectively can learn to use aspects effectively. Unfortunately, I think that's less than half of all professional developers.



I am a lecturer in Symbiosis Institute for Information Technology. I was afraid whether it would be beneficial to learn AOP and AspectJ. This article I think will certainly help me in positive direction. I agree with AOP approach to deal the problems.

Thanks for allowing to share the views.


The comments to this entry are closed.