techno.blog("Dion")

Erik Hatcher finally had some time to grok AOP and AspectJ. He got quickly up to speed (as he normally does) and saw a use for it right away.

The one feature that has bothered me about Tapestry is its difference with what happens when validation fails compared to Struts. When validation fails, the listener method is still called in Tapestry, and this requires a bit of code to handle it *in every single listener method*. While I’m still on the fence on whether Tapestry should itself avoid calling a form listener method when validation fails, in the apps I build it is always the case. AspectJ came to my rescue. I created this aspect…

public aspect ValidationAspect {
void around(BasePage page) : execution(void
Home+.listener(IRequestCycle)) && this(page) {
ValidationDelegate delegate = (ValidationDelegate) page.getBeans().getBean("delegate");
System.out.println("aspected: " + delegate);

if (!delegate.getHasErrors()) {
proceed(page);
}
}
}

That piece of code looks for anything that implements Home base class / interface (Home+).

It would be nice to make this generic for anyone using Tapestry as Erik has said, so that it would only be called on org.apache.tapestry.form.Form listeners (via a cflow()).

Nicely done Erik :)

I had a nice chat with Jon Tirsen. We talked about Groovy, AOP, Domain Driven Design, LISP, Ruby, Sydney, and bad beer.

Side Note: Aussies don’t care for Fosters:

Fosters: Australian for crap

and their Victoria Bitter is a lager not a bitter!

Anyway, while talking about http://intentsoft.com/ Jon came out with the above quote:

“AOP is just the stuff that makes OOP work”

I am really looking forward to getting the Domain Driven Design and seeing how it fits into the Microsoft DSL stuff.

Rickard has spoken up to the concern that Gosling had on AOP:

Rickard Oberg

We have been using AOP (note the “P”) since July 2002, when we started building our CMS product SiteVision. Many on our team used to work on another similar product for another company before, and it’s interesting to look at some of the metrics. In half the time, with roughly half the code, we have twice as many features implemented as the other product. We’re 5 developers, but since we also do installation, training, support, and sales, I’d say we have had about 6 man years of effective development time. To go from scratch to top-five CMS’s in Sweden in such a short time, and with such a small number of developers, is a pretty decent thing to accomplish methinks.

Our typical time from idea-to-implementation is roughly between two days and one month, because typically we can reuse 30-80% of a new feature by using already built aspects (both advice and introductions).

We have, among many other things, implemented replication, client-side undo management, transactions, transparent partial object state versioning, security, locking, etc. as aspects, which we can reuse on any component or object model. Whenever we start on a new feature all such things are already there and “just works”.

I do know that we are probably an anomaly when it comes to using AOP, both in what we use (=homegrown) and how (=throughout product), but I still think it’s a good sign that AOP as such is not only viable, but can be a *key factor* in developing competitive software. I can safely say that *without it* our company would be dead by now.

Oh, and it’s both performant *and* maintainable. How ’bout that!

James Gosling

AOP is kind of a complicated one for me, because AOP is one of these things where the theory sounds really good. I actually mostly like the theory. The way it turns out in practice tends to be pretty dangerous. It’s fraught with all kinds of problems. You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren’t very many use cases outside of that. And when you find people who are using AOP, the average ones that I’ve talked to have been using it for things that are just like incredibly inappropriate. It’s like a really, really, really bad idea to be doing what they’re doing. And so I feel very conflicted because on the one hand I basically like the concept, but I don’t think that the research community has really figured out how to encapsulate those in a mechanism that really works for people. It’s like giving them a chainsaw without any safety instructions.

People have replied to Rickard saying “well. your opinion isn’t valid for the Real World, as you are smarter than the average bear”.

This has been said many times over the years hasn’t it. We could look at this point in a few ways:

• Yeah it is different and dangerous. Let’s never touch it, even though it can give us benefits
• I will use it cautiously. No need to jump on AOP for everything today, but I can incrementally use it (policy, testing, debuging, etc before going to production)
• It is very powerful. I see this as a GOOD thing. This will be my secret sauce, and will enable me to deliver faster than the cautious ones.

Rickard has gone with #3, and is able to do just that. Would a junior guy be able to jump into the codebase? Maybe so, maybe not. Who cares… his company is thriving.

NOTE: Just because AOP is being used, some junior guys wouldn’t have to be in those modular concerns, and their code would be SIMPLER because of it!

Are you an Eiffel fan that wishes this Design By Contract stuff was available in Java?

There are a few tools out there to help, such as iContract: Design by Contract in Java.

AOP offers a nice way of working with these anal pre and post conditions ;)

Your Java code often needs to interact with external components when you develop enterprise software. Whether your application must communicate with a legacy application, an external business system, or a third-party library, using components you don’t control introduces the risk of unexpected results. IBM IT Specialist Filippo Diotalevi shows how aspect-oriented programming (AOP) can mitigate this risk by helping you design and define clear contracts between components while keeping your code clean and flexible.

Read Apply Design by Contract to Java software development with AspectJ

The Spring Framework seems to play nice. They have their own MVC framework, yet you can plugin any that you may wish (WebWork, Tapestry, Struts [sorry], etc).

There is a similar story with AOP. Spring has its own AOP, and an intro article was just published: An Introduction to Aspect-Oriented Programming with the Spring Framework, Part 1.

However you aren’t stuck with the one AOP alternative (Spring AOP). There has been a lot of thought put into integrating with other AOP implementations.

Here Rod talks about this and AspectJ integration:

“Having said that, I believe that AspectJ is going to become increasingly important as we come to understand the full implications of AOP. So one of the major features in Spring 1.1 is AspectJ integration. This will allow AspectJ aspects to be configured by the Spring IoC container using Dependency Injection, which brings similar benefits to applying DI for classes. Both Adrian Colyer and I are very excited about this, and both Spring and AspectJ teams are working together. Support for the core AspectJ integration is already in Spring CVS and will be released with Spring 1.1 RC1 (probably end of next week). I’m also working on some samples, which will probably be released separately slightly later. The Spring/AspectJ integration opens up some interesting possibilities. Beyond that, we’re looking at using AspectJ pointcuts to target Spring AOP advice. This relies on AspectJ changes–they are going to expose an API for Spring and other tools to use at runtime. Another interesting area is implementing Spring services as “native” AspectJ aspects. Thus we’ll provide a transaction aspect, probably in the Spring 1.2 timeframe, although I might release it with the samples.”

Well, there is also support for AspectWerkz AOP with Spring via the Spring Aspect Container

The Spring Aspect Container in AWare will make it possible to manage your aspects using Spring, it let’s you treat the aspects just as any other Spring bean.
The container will read in a Spring configuration file called aware-config.xml, this file has to be on your classpath. In this file you can define your aspects, add parameters and data structures to them, pass in references to other components that is being used etc. This is for example documented briefly in the Role-Based Security section.

We are spoiled for choice :)

Dale has put together AspectJ in Two Paragraphs.

In this instance, we are researching the use of aspects to assist debugging an existing Java application. It has several different sources of data access and no single place in which to place logging or parameter setting logic. As such, we have found it very labor intensive to reliably search out all of those points and cut-and-paste the same code to every one of them. AspectJ allows us to define “pointcuts”, or semantically well-defined places, where the existing object-oriented code can be prepended to, appended to, or wrapped by, “advice”. Pointcuts and advice will allow us to consistently log all (diversely implemented) database accesses using only one definition (the aspect file). The advised code will add an identifier to every SQL statement in the application before it is executed by DB2. The advised code will also set the necessary JDBC parameters on every connection to enable additional tracing information produced by DB2. Because there is no editing of the actual codebase, the chance of code drift and bug introductions can be minimized. The chance that side-effects will be introduced into the codebase is almost non-existent since aspects cannot be directly referenced by Java classes. Aspects exist outside of existing code and, if they do not contain application logic themselves, can be selectively added or omitted during the Ant build.

I expected to hear about some cool marriage of AspectJ and JINI :)

Of course, Adrian Colyer did a great job of explaining AOP without the buzzwords.

Bill Gates had a nice little brekkie with some New Zealanders. He mentioned embracing AOP and MOA:

Davidson was more interested in a discussion about developer productivity and code reuse. Gates told the architects that Microsoft would be embracing model-oriented architecture and aspect-oriented programming. (Model oriented architecture, or MOA, describes a system that uses modelling and metadata in its construction and at runtime. Aspects identify key areas of functionality within applications

It looks like MOA will be the new acronym (and partner of DSL [domain specific languages])

I really like the new feature in AspectWerkz 1.0.

They have a notion of an AOP Container in that you can deploy aspects and aspect libraries as components.

You just need to setup an aop.xml such as:

<!DOCTYPE aspectwerkz PUBLIC
“-//AspectWerkz//DTD//EN”
“http://aspectwerkz.codehaus.org/dtd/aspectwerkz.dtd”>

<aspectwerkz>
<system id=”webapp”>
<aspect class=”demoAOP.DemoAspect”>
<pointcut name=”allPublic” expression=”execution(public * *..*.*(..))”/>
<advice name=”trace” type=”around” bind-to=”allPublic”/>
</aspect>
</system>
</aspectwerkz>

The aspects only affect the area that they should via:

Note that if an Aspect is deployed within an application, the pointcut it defines will be limited by the class loader isolation principle. Even if the pointcut assumes to match all method in all classes, it will only “see” all methods in classes loaded by this classlaoder and the child classloader.

Cool stuff. It would be fun to have Spring grok this aop.xml file too :)

Read Alex’s tutorial: How to integrate Aspects in J2EE apps with aop.xml

There is YA-AOP article, this time using JBossAOP for examples.

I really liked Andy O’s thoughts:

He just says the wordy equivalent of “rope is dangerous because it can form a noose and hang you”, but doesn’t tell us “it can also tie ships to harbor, tires to trees for kids to swing on, anchor kites to those flying them, etc.”

I agree. Rope isn’t always a bad thing. Just make sure you use the correct rope. Don’t tie your shoes with shipping rope, and don’t tie your ships with shoestring.

Bob has written about refactoring dynaop Factories using dynaop.

It definitely feels that many of the patterns that are out there, are hacks to get around a lack in the particular language/system that you are working with.

Factories are definitely an annoyance for me. Having to create factories for various types is just a pain, especially when they are often trivial implementations.

I really like how I can use introductions/mixins with certain languages. I then really like being able to:

• Setup an interface
• Have the interface contain an introduction which can handle returning an implementation of that interface