I appreciate the conversation we are having. This is potentially the most targeted response that I have ever seen about aspect oriented programming.
Most importantly you say: "OnJava willing, I plan on writing a follow-up article showing how you can apply system-level aspects of JB4 to POJOs." I too would like to see another article on AOP, but I would rather see you address these fundamental issues about what it's good for, what it's not good for, where it fits into the architecture, at a high level. NO CODE. I know the 'no code' thing is against all that O'Reilly stands for, but really, a conceptual and architecture article is required once and a while. Not all concepts are best taught in 9pt Courier.
Let me put it a different way. You are too close to the oven because you are assuming a great deal from your readers. I work in a well known software company (not M$) with a great team of bright engineers. I took an informal poll after I started this thread yesterday. Of the fifteen I talked with, only five knew of the term 'aspect oriented programming'. None could define it as to what it mean or it's use.
The article you have here skips right over 'what is AOP', jumps over 'what is it good for', ducks straight around 'what are the advantages and disadvantages', and heads straight into 'this is how it works, here is a little command line song and dance'. You left 99% of the audience at the door. Notice that only two people responded to your article the first day. An article on the front page of OnJava and listed above the fold!
Ok, now off my soapbox and into your very kind response:
"Will you be able to determine what is actually going on?" - Yeah, this goes right to the heart of my debugging issue. I can see it right now. A couple of months into the the project everyone is happy. AOP is running cool and snappy. Then at crunch time when the bugs are flying around like mad people will be banging their heads into walls trying to figure out "what is actually going on", and ripping out aspects left and right to get back to "real code".
Much like threads, I can see AOP turning good code into chaotic goo where engineers return from three day bug hunts with five mile stares mumbling "I stared into the abyss and it stared back."
"the first killer applications will be applications like JBoss that leverage AOP to provide J2EE and beyond J2EE functionality to POJOs" - So if this is the killer app, then why not write it and talk about that as the article? Why is it the next article? Certainly chromatic would have preferred that? Why go back a rehash the same old 'tracing and logging' story we have heard since the beginning of AOP. Honestly, if it did logging really well, it may be worth using just for that. Just because you have a new tool doesn't mean you need to apply it to everything. Perhaps we should be happy with AOP for logging and leave it at that. Remember Dave Thomas' "Golden Hammer" principle.
"AOP names patterns that many software developers have been applying for years and encapsulates them within various frameworks." - This is just the kind of statement that deserves a full article? Which patterns? Dependency? Observer? Oracle's Fastlane? ;-) (I just threw that last one in for my own kicks.)
"EJB is pretty static, but think about what you're doing when you're writing a bean. You're applying system aspects to a class." - Yeah, I understand AOP (well, at least I think I do), and I certainly understand EJB (though it's not a pleasant thought). But I don't understand this statement. Again, another thing to address in an article. Summarized as, "how is what I am doing today akin to using aspect oriented programming?"
"With Declarative programming and AOP as the glue, we have a real chance to really simplify things. Not through some fancy, expensive IDE, but through the language and framework itself. Go look at .Net and you'll see what I mean." - I have looked at with and worked with .NET and as always, Microsoft knows how to build a fast block query architecture. They also know that you can map a table to one class. Unlike J2EE which takes five classes and two interfaces per table. But all you really need to get to the .NET is to use straight POJOs talking to JDBC. I just looked up "Apsect Oriented Programming" on the MSDN, "No Topics Found". Microsoft doesn't think the need AOP to have solid and simple data access in C#. Do you think Java that different?
"Rickard Oberg's company is building a CMS system upon AOP with success" - This would make for a fascinating case study to get people on board with AOP.
"The biggest con is that AOP provides too much flexibility." - Seriously, here are some cons:
* Maintenance programmers won't know AOP from ASP and will reak havoc.
* Engineers will forget the aspects because they aren't right in their face, and will spend days searching for bugs in one class when they are really in an aspect in some other distant corner of the program.
* You can have hairy aspect ordering problems.
* There are issues getting aspects to talk between each other.
* You can be working on a system without robust unit tests (like 99% of the systems in production) change an aspect and break pieces of the code you didn't even know about.
* Aspects can cross component boundaries freely, with adverse effect.
* I can imagine having to impose and 'aspect lockdown' well in advance of a code freeze so that system wide changes are not made close to release.
Saying that the only downside of a new technology is that it allows "too much flexibility" is glossing over reality. If you want to see engineers you have to be up-front about the technology warts and all. Every technology has problems.
Expecting that you can just take a technology with as much power as AOP and walk it into any production shop, lay it one the table and say 'bye' and have everyone use it is unrealistic. You have a lot of educating to do and process to indocrinate before you succesfully deploy AOP.
Again, thanks for the conversation. It's been great. I'd love to see AOP take off, and it's going to take conversations like this that educate, inform and address the misoneism indocrinated into software engineers.