"1) Having done it in the past doesn't make it the right thing to do. You don't think it's a red flag that to implement basic database transactionally functionality we are hacking byte code?"
XDoclet with JDK 1.4, JSR 175 with JDK 1.5 declares the behavior you want. AOP provides the glue for system level constructs. For JBoss AOP + XDoclet now?
* @jboss-aop.metadata group="transaction" trans-atribute="Required"
public void somePOJOMethod()
You write simple basic database logic, define simple metadata tags for the transactional behavior you want, and AOP glues in the appropriate system-level code.
I mean its just plain ridiculous that for EJB you have to spend money on fancy IDE or generate mounds of code to get that kind of simplicity. Tools aren't the answer. To reduce complexity the architecture has to change.
C# has it right with with their metatags, JSR 175 is playing catchup. For now, JBoss AOP metatags + XDoclet can provide this type of declarative programming.
"2) I'm not actually running the examples. The question remains, can I use the standard IDE debugging tools to debug through both the aspect code and the standard class code in a straightforward manner."
You should be able to. Line numbers and debug info is preserved.
"3) The reason we have the term POJO is that engineers were burned by having an EJB 1.0 standard that could not be deployed. The very idea of 'bringing EJB to POJO' is defeating the point."
Defeating what point? That to get simple transaction demarcation you have to write a Home, Remote, and EJB class, an ejb-jar.xml file, and a vendor specific deployment descriptor and package it within a jar?
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.
"4) I'm the adminstrator adding a user to the user table. After one level of nesting within the transaction you have the potential for a read lock. Or are all of the transactions within a transaction restricted to being within a single method?"
Like any good component writer, the aspect writer needs to think and solve these types of issues. You're in luck. JBoss has been built on interceptor technology since 2000. JBoss AOP security leverages this technology.
"I think you are missing the larger point. I am an experienced programmer with a lot of production work under my belt and I am interested in AOP."
I too have a lot of production work under my belt. Besides actually implementing many parts of the specs themselves, I've applied DCE, CORBA, and J2EE to various in-production applications over the years.
These specs are VERY useful for the functionality they define, but really get in the way of writing actual application code.
"From what I have seen so far I, like many others, have stayed away from AOP because of well founded issues like these. But also because AOP is a paradigm shift, possibly a larger paradigm shift than object oriented programming. In order to get people up over that hump the AOP advocacy community is going to address the fundamental issues that surround revolutionary technology:"
Have you written EJB's? Then you've applied the fundamentals of Aspect Oriented Programming. Sure, 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.
"1) What is the compelling value."
Simplicity and flexibility. A better, simpler contract between the system developer and application developer. A layered approach to programming without the syntactic sugar.
2) What are the pros and CONs
The biggest concern I have is: Will you be able to determine what is actually going on? This is where tools will have to come in the picture.
The biggest con is that AOP provides too much flexibility. The hurried, lazy, or ignorant programming could use AOP to bandaid their code, instead of iterating and producing a better design.
3) What are the killer applications.
Iona's Corba implementation, Orbix 2000, was written on interceptor technology, and so is JBoss. Rickard Oberg's company is building a CMS system upon AOP with success (www.dreambean.com).
I guess, the first killer applications will be applications like JBoss that leverage AOP to provide J2EE and beyond J2EE functionality to POJOs. AOP fits very very nicely in implementing and applying frameworks like J2EE and CORBA.
"4) OOP was a better mapping from the real world to the software world. Does AOP provide an even better mapping. If so, how?"
As I said above, I think AOP fits best with system level constructs. The only application-level aspect I can think of now is Billing.
"These issues need to be addressed before you can realize this vision of AOP leading the technology wave over the next 15 years."
AOP names patterns that many software developers have been applying for years and encapsulates them within various frameworks.
"Object Oriented Programming wasn't immediately embraced. There were a lot of doubters then, and there are still some now (though I am not one). In order for OOP to become popular the supporters had to twist of lot of arms and minds. I'm sitting here begging for my arm to be twisted and simply seeing a bunch of code and some assumptions that AOP is just 'right'."
When we ran into the definition of AOP early last year, we were like, "Heck, we've been doing this type of stuff for years! We could really bring our technology to POJOs!" Hence JBoss4.
OnJava willing, I plan on writing a follow-up article showing how you can apply system-level aspects of JB4 to POJOs. Until then, visit www.jboss.org. We're applying AOP in a multitude of different ways!
BTW, these are great questions! Skeptics are needed otherwise you end up with crappy code and frameworks.