techno.blog("Dion")

I had a bizarre email which talked about an information week article.

I saw:

Hardware considerations can muddle the seemingly lower cost of Linux ownership, The Advisory Council says. Also, aspect-oriented programming needs to mature before it’s ready for prime time.

The way the claim about AOP came into the sentence surprised me so I took a look.

The question asked was “Question B: What is aspect-oriented programming, and should I be interested?”

The answer gave the usual…. but my eyes opened when I saw the phrase:

… and coding “cutpoints” for each aspect…

Maybe I won’t listen to the judgement ;)

Read: What is aspect-oriented programming, and should I be interested?

I just got a message over the vine from Gregor Kiczales. He, Adrian Colyer (mr. aop blogger of the moment, oh.. and he is lead for AspectJ), Mik Kersten (AspectJ IDE plugin man), and Gail Murphy (leads research in non-language tools) are having a 2 day course on AOP.

Gregor Kiczales and colleagues are offering a two-day AOP course this fall in Vancouver. The goal is for attendees to get a solid understanding of AOP, as well as the ability to begin discussing how their own company should explore AOP in an expedient but risk-managed way. See http://www.cs.ubc.ca/labs/spl/aop-course for more details.

I want to go! :)

Anders was asked (and is being asked a lot at the moment), what his thoughts are on AOP, and how it will fit in with C#.

Anders is in a “wait and see” mode. He sees a little wary of the fact that “If I look at my code I don’t know exactly what is happening”, as someone may be weaving in. This sounds a little bit like the people that were wary of polymorphism at first, as they didn’t know what was really called. I think it would be good to show some code with and without AOP, and how you get MORE clarity in your code with it (in my opinion). I do think it is wise for Anders to be wary though, but it is good to hear that he is paying attention. He did say that he thought that Attributes were doing part of the job. I worry about people confusing Attributes and AOP.

I think there is room for Gregor to talk to Anders to have a really good discussion. In fact, there is room for this with a bunch of the Microsoft people, who are definitely poking AOP…. and could probably do with some nice information.

Sun has recently shown that they are a little skeptical of AOP. I hadn’t heard anything from Microsoft on the matter, until I got a glimpse yesterday.

I was in a talk by Keith Short on “Tools for SOA”. It turned out SOA (Same Old Application?) was really put out there to lure in the buzzword biters :) What the talk was really about was Microsoft’s vision for modelling. Keith went through where he think CASE went wrong, and that Microsoft think that there is much value in modelling… so we can’t just give up.

Keith walked us through some DSLs (Domain Specific Languages) that are in VisualStudio 2005, showing the higher level abstraction and how it is useful. He told us how if you tool is generates reams of code, you will not succeed. Round-tripping doesn’t work. Microsoft wants “Tripless” (Martin Fowler term).

On a few of the slides for these domains, you would see the header “Aspects”, and under them some cross cutting concerns. I asked Keith about this after his talk, and he said that Microsoft sees a lot of value in modularizing cross cutting concerns, but is scared by code injection. “That is the point!” Microsoft gets AO, and wants to use it in some way in its tools. They need to know that it isn’t about using code-injection, and they are already thinking in the right way. There is such a natural fit for AO in the high level languages that they are building in this modelling framework, and I hope they take a serious closer look at AO and don’t get caught up in some of the implementation details.

Cedric has written an interesting post on AOP and annotations.

I think things are going to get a little hairy here.

The main problem is that we can start chasing out tail:

xml -> annotations -> aop to put in the annotations -> xml to define how aop puts in the annotations -> repeat

I think there is going to be some art when it comes to knowing WHEN to use annotations.

I don’t think that it makes sense to annotate on major cross cutting concerns. The obvious example is having to put @loggable on every method ;)

I guess annotations will allow you to tag some cross cutting concerns when they don’t fit the pattern. E.g. setterDogsAreNice(). There could be an annotation that lets the system know that this is NOT a property. However things get dicy.

We are all going to go hog-wild with the new shiny toy that is annotations. It is human nature :) Over time we will work out the subset of items that should use this style, and the areas in which you shouldn’t. Having code with a ratio of 100:1 annotations:code is going to happen, and it doesn’t seem to readable to me.

So I think there will be SOME marriage between AOP and annotations, and it will be interesting to find the balance. I mean, some annotations can be considered a cross-cutting concern ;)

*runs off after his tail*

Adrian Colyer has created a new blog.

His first post was on how you can use AspectJ to invoke AOPAlliance compliant interceptors (those from Spring, dynaop, etc).

Read Integrating AspectJ and AOP Alliance based aspects

I was taking part in the AOP panel discussion at last weeks TSS symposium, and listening to Rod Johnson and Bob Lee describe how dynaop and Spring can share aspects since they both implement the AOP Alliance interfaces. Sounds like both projects have some great aspects already written, and with more to come the obvious question crossed my mind: can I use aspects written to the AOP Alliance interfaces from within AspectJ?

A few hours later and I had a solution that lets you use the expressive power of AspectJ’s pointcut language to invoke advice (interceptors) written to the AOP Alliance interfaces, and to freely mix and match AspectJ and AOP Alliance advice in the same program, even applying at the same join points. Here’s how it looks…

Welcome Adrian.

Rickard is talking about how to implement domain models in AOP which includes both behaviour and state.

Although some blogs mentioned being tired of AOP from the symposium… this wasn’t the norm.

I had ~40 or 50 people come up to me at the symposium…. all saying that they are going to take a close look at AOP (after the various talks). Even at an event like TSSS, with high caliber people, the majority of people have only heard of the term AOP. A small percentage have really started to play with it.

This actually makes presenting on AOP at this type of event tough. The baseline is across the board. You have people like Sam Pullara in the audience…. and then of course Gregor and Adrian :)

The aim was to spread the word… show people some of the things that you can do, and hopefully they will pick up a book… download a framework… and start to play a little. If that happens, we have a win.

Wow, what a busy few days in Vegas for TheServerSide Java Symposium. It feels like one loooooong day, with time running so fast, and the casino showing you constant daylight.

It was interesting to see the show grow from last year. It is really all about the people. The entire community makes this event what it is. If you looked around the event you see:

• Talks: The presentations were quality, and by smart people
• Collaboration: It was so great to see people from various companies, and open source projects, coming together to discuss things. As good as the talks are… it is this collaboration which makes the event so much more. Here you can see Spring, Dynaop, and AspectJ leaders talk about issues and techniques that the employ within AOP (or should I just be saying AO now too ;). Various frameworks discuss how they can leverage eachother…. how best to plug together…. and generally play nice. It also gives the users a chance to talk to the project leads on apps that they are using day in, day out. This feedback loop is so important. This was shown by the JCP, and how keen they were to listen (thanks Onno and company).

Let’s face it. You can’t beat face to face communication. Having a beer with someone, and connecting with them in general does wonders. When you are emailing eachother you can picture the other end. You *get* who they are a little more.

Anyway, I was really excited to see the community together. Thanks for making it all happen. I look forward to seeing you all next year!

There are certain aspects that are ripe for reuse. There are various levels of reuse of course (totally generic: Log4J, company-reuse: YourCompanyLogger, etc).

A common pattern that you run into, (we use it in aTrack. Ramnivas has it in his book, etc) is that you want to apply some advice, but only to a subset of your code.

The simple way to do this is to use the template pattern:

First, define the abstract aspect which does most of the work, but leave open a scope() pointcut:

public abstract aspect PolicyEnforcement {
  abstract pointcut scope();

  pointcut printing():
    get(* System.out) || get(* System.err) ||
    call(* printStackTrace());

  declare error: scope() && printing():
    ”Our policy enforces the fact that you have to print via our logger”;

  declare warning:
    call(Exception.new()) ||
    call(RuntimeException.new()) &&
    scope():
    ”constructing exception without

We have learned to teach OO programmers to Favour Composition. Why do we do this?

Because inheritance is bad?

Of course not. inheritance is a very powerful design tool at our disposal. If you imagine taking it away from your arsenal (not the damn English football team that I dislike ;) ) you would see people weeping.

When inheritance fits a problem it is elegant and beautiful to behold. If you had to use another technique it would feel like a hack. That is how you will feel if you learn to use AI techniques and they were suddenly taken away.

The problem is that when you use these powerful tools for evil instead of good, then you end up with a grimace. A crazy inheritance hierarchy is an incredibly brittle software design, and will constrain you.

Human nature is to play with the new shiny toy (well for some people. The cynics just complain in the corner). You have to make sure that the toy doesn’t overwhelm you and influence your design decisions. If inheritance doesn’t feel right…. don’t do it!

So, back to Favouring Composition. By planting this seed into a developers mind, they will hopefully think for another nanosecond before they make the Car extend Engine, just because they want to get some of the methods for free.

Thus, my mantra to myself is Favour traditional OO interfaces when designing with AI in my kit bag. With this seed I stop myself from jumping to the oh this would be fun if I wrote an uber-aspect which could do X, Y, and Z!. It doesn’t mean that I won’t use AI techniques when the shoe fits though… and when they DO fit, man are they warm and comfy slippers.