| RE: [aspectj-users] Philosophical Questions |
Ron,
I actually had a chance to pull Bill Burke from JBoss aside at TheServerSide Symposium and we talked a bit about their vision for the framework. What is interesting about their approach is that although they are providing the underlying framework, they really don't see many developers writing their own middleware aspects. Instead, they expect users will stick with the provided library of aspects, probably via their integration with Xdoclet.
I see this as both a step forward and a step back. On one hand you have one of the first large collections of reusable aspects to choose from, but on the other hand the message is that aspects are probably beyond the average developer. This issue of complexity just keeps coming back again and again whenever AOP gets mentioned.
Although AspectWerkz is arguably the furthest along in providing a complete AOP solution, I haven't seen anything in their implementation with respect to control flow join points. Perhaps I've missed something. It does support pertype aspects, however, so that earns points in my book.
I agree with your points on the hidden complexity of the Java AOP frameworks. I think this is the nagging doubt I've had when evaluating them. There is definitely an attraction to the idea of a simple framework to enable AOP concepts, but it is perhaps too early for developers to experience the challenges that come about with lack of tool support, etc.
Your metadata-enhanced Java syntax is interesting, although it bears a strange resemblance to some of the object-based scripting languages. Perhaps this is where the next generation of AOP programmers will come from :-)
Cheers,
Merrick
-----Original Message-----
From: Ron Bodkin [mailto:rbodkin@xxxxxxxxxxx]
Sent: Monday, July 07, 2003 9:23 PM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Philosophical Questions
Merrick, thank you for raising the issue and to those have already responded. I too have been thinking about this issue for a while. I will admit my bias: I think AspectJ is still by far the best choice for AOP developers.
AspectJ users need to "stand up and be counted". Posts to this list demonstrate that developers at many enterprises and ISV are solving real problems with AspectJ. We need to be more visible about how we're using it and both where the technology works well and where improvements are needed. The AspectJ community also needs more build reusable libraries of classes and aspects that increase power and ease of use. Jan Hannemann's implementation of the GoF patterns is a great example (http://www.cs.ubc.ca/~jan/AODPs). Several papers have described other promising candidates (e.g., A. Rashid and R. Chitchyan in "Persistence as an Aspect").
I am skeptical that the new AOP frameworks are easier to learn and use (though they do avoid the challenge of adopting a language extension).
I believe AspectJ will benefit from allowing dynamic weaving for infrequent use cases, but that this is far more the most critical issue for effective use of AOP. Instead, users to be visible about how AOP works and to identify where they would benefit from pre-packaged libraries of aspects and helper classes.
Having said this, let me offer a more in depth comparison of features of AspectWerkz, Nanning, JBoss AOP, jAdvise and AspectJ. I believe these frameworks aim to deliver three things: simple adoption, highly dynamic support, and immediate utility for enterprise development.
I see great tension in the two goals of simple adoption and dynamicity. Most of these frameworks strive for (and some already implement) dynamic AOP in the sense that a program can apply or remove an aspect (advice and/or introductions) to a specific (object) instance at run time. Just as highly dynamic OO lost out to mostly static OO because it is easier to understand and to avoid programmer errors, I think highly dynamic AOP will not win. It's generally impossible to provide useful tools support at development time to identify dynamic advice or introductions. It's true that dynamically applying an aspect is somewhat easier to understand for a newcomer than cflow constructs.
I do think extending purely static AOP with dynamic capabilities is occasionally helpful, just as Java benefits from occasional use of reflection. One obvious case is debugging. The various AOP frameworks have published other use cases: JBoss AOP for making object state transactional and replicatable, and Nanning for testing (in cflow-like constructs), etc. The JBoss use cases are interesting, and driven by the goal to provide useful aspects for end users. They have done a great service by raising the importance of useful aspect libraries; the AspectJ community would profit greatly by learning from this and providing useful prepackaged aspects (and classes).
It's true that a Java framework (combined with a "little language" in XML) is easier to sell on many projects than a language extension like AspectJ, and it avoids breaking tools that rely on Java source. However, I think these frameworks are *harder* to use:
- Writing interceptors is a step backwards from advice with typed parameters. They require lots of casts and painful code to unpack parameters at runtime. Indeed, you can argue whether they aren't just metaprogramming (a predecessor to AOP).
- As others have posted, they offer "simpler" pointcuts and languages by just removing powerful features of AspectJ (declare error/warning and declare parents are universally absent). AspectWerkz is much closer (because it does support cflow, pointcut composition, reusability, and caller-side method pointcuts though not with around advice). These features are in the language because they're useful, especially as you do more real AOP. But you can start learning and using AspectJ without them. The future of pointcuts is raising the level of abstraction so they can describe what's really happening in a program (Gregor made this point eloquently at his keynote at AOSD 2003). We need more power and _expression_, not less.
- XML hell. There's a good reason J2EE 1.5 will be moving programmers *away* from writing XML deployment descriptors into using metadata tags embedded in code. It's no fun coding in XML and as Gregor suggests the tools available for matching up XML descriptions and code are primitive (in my experience they are non-existent).
- Modularity. I agree with Merrick that breaking an aspect into various Advice and Introduction classes is a step away from good modularity.
- Documentation? AspectJ has had three books and numerous tutorials and articles published for new users. What is available for prospective users of these new frameworks?
- Efficiency? The various frameworks claim to be extremely efficient in their dynamic weaving. It will be interesting to see proof in terms of large scale deployments.
I do like the way JBoss AOP supports metadata with XDoclet today. Support for PCDs that use metadata tags is valuable. If there were enough AspectJ developers, I'd love to see early metadata support in AspectJ using XDoclet. But I think it's more important to support JSR 175 in time for J2SE 1.5.
I would like to see something more scalable, that lets projects start with a simple, easy to use model and easily move up to AspectJ. I could see value in an "AspectJ light" that uses metadata tags to capture AOP concepts in pure Java code, e.g.,
@aspect abstract class Tracing {
@pointcut("abstract") void scope(Object target) {}
/* alternatively:
@def("(Object target)", "abstract") Pointcut scope;
*/
@pointcut("scope(target) && call(public * *(..))")
void entries(Object target) {}
@after("scope(target)")
void logEntry(Object target, JoinPoint thisJoinPoint) {
System.out.println(thisJoinPoint+" from "+target);
}
}
To me, this is much better than an aspect in disembodied Java classes plus an XML file. It's *worse* than AspectJ, but it may be worth having it available so projects can start with pure Java AOP and then move up to AspectJ.
Finally, the various blogs and enterprise AOP frameworks have made a useful contribution in raising questions of how AOP can benefit enterprise development, including proposed use cases. The JBoss set is impressive, e.g., "J2EE a la carte", remoting for POJOs, transactional objects, and "replicated cached" (see http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop). The other frameworks address use cases that are well known in the AspectJ community (e.g., Nanning's list at http://nanning.snipsnap.org/space/Aspect+Pattern).
AspectJ users need to be more vocal in the debate about the usefulness and ease of adoption of AspectJ, and to identify more useful libraries for AspectJ developers to build on.
Ron
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
> ------------Original Message-------------
> From: "Frank Sauer" <Frank.Sauer@xxxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>
> Date: Mon, Jul-7-2003 12:05 PM
> Subject: RE: [aspectj-users] Philosophical Questions
>
> I've attempted to straighten out some misunderstandings
> about AspectJ on one of these, but my impression is that
> once the owner of a blog has made up his mind that he/she doesn't like
> AspectJ it is very hard if not impossible - to convince them. The
> problem with BLOGs of course is that they have an owner/moderator who
> is biased, they're not open forums.
>
> These frameworks are "AOPish", in my mind, not full-blown AOP. I
> believe everybody calling everything AOP these days could be a big
> problem for the future of "real AOP", as Gregor already pointed out.
>
> Frank
>
> -----Original Message-----
> From: Gregor Kiczales [mailto:gregor@xxxxxxxxx]
> Sent: Monday, July 07, 2003 2:45 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] Philosophical Questions
>
>
> I just google for "AOP blog" or "aspectj blog". Or "ted neward blog",
> "rickard oberg blog", "cedric buest blog", "aspectwerkz", "nanning"...
>
> There's also jboss.org, and aspectalliance at sourceforge.
>
> And a bunch of others too!
>
> Eric Eide said:
>
> >
> > Remind me: where are these blogs?
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/aspectj-users