techno.blog("Dion")

Jonas keeps plugging away, and the release candidates keep shipping for AspectWerkz.

Even though it is mainly a bug fix release, the team has added some nice features:

• Aspects does not have to extend the Aspect base class anymore, but can be any Java class and extend anything they like
• The JoinPoint class has these two methods:
  • getSignature()
    - which is used to retrieve the static signature for the join point.
  • getRtti()
    - which is used to retrieve the RTTI (Runtime Type Information)
    about the join point.

  Both these methods returns a base interface that could be used, but is usually best to cast to a more fine-grained and specific type.

• Retrieval of information about the system, adding and reading of parameters and metadata etc. is done through the CrossCuttingInfo
  class. An aspect or mixin that is interested in accessing this info should have a constructor that takes a CrossCuttingInfo
  instance as its only parameter.
• Pluggable aspect container – The possibility to provide your own aspect container implementation is back. Useful if you need to control how your aspects are instantiated for example if you want that to be handled by an IoC container (Spring, PicoContainer etc.))

Read the announcement: AspectWerkz 0.10 RC2 released

There was a lot of buzz when Tim Bray joined Sun.

I am very impressed that he has kept up the blogging, and it is very honest. He talks about what is good, and what needs work.

I think he is making a difference, and his latest entry talks about the new Sun Policy on Public Discourse.

Hearing more from Sun can only be a good thing for them. They do have a lot of smart people working there (maybe not so many in the marketing department unfortunately :/) and it is great to see a more open voice.

Hopefully they will connect more with the community. I have noticed a difference with the JCP recently (it has been a pleasure to work with some of them), the process is getting more transparent, and the spec leads are opening up more.

Now we need a few more Sun Java evangelists out there. They should be in the community (TSS, JavaLobby, …) listening to developers. This goes hand in hand with my past entry Sun should call in their MVPs!.

Sun, we are out here waiting to promote the technology. Use us.

A good mate from Colorado, Luc Nadeau, just published a new online magazine named Purgatorius.

About the Mag

Purgatorius is an organization of artists dedicated to creating ideas, images, and writings that inspire a progressive evolution of human socialization

It is so interesting to watch up we take input, and somewhere in the process it gets munged up in the brain.

I do this all the time. When I look at something I just typed, such as a piece of code, I don’t see what I typed at all. Nope. I see what I thought, wanted, and should have typed.

I was talking to another kind soul today about AOP. I happen to be a fan, an advocate, or whatever you want to call it. Does this mean that I believe that if we all start to use AOP that software will suddenly become simple? Suddenly we will not make anymore mistakes in our design? Of course not. This is just a tool folks. A tool that can help with the complexity of cross cutting concerns.

How many cross concerns are out there? A bunch… Is everything a cross cutting concern? Not even close.

I was told that the AOP guys are touting that it is the best thing since sliced bread, that it is a saviour, and that this is going to bring on a nightmare as people abuse it. I asked the fellow to show me ONE example of a thought leader (using the term just to piss of Hani) in the AOP space saying this. Of course he couldn’t. The real thought leaders rarely do!

AOP is a great tool, but just like we have learned to favour compositionin OO, we should favour OO interfaces compared to AO. What does this really mean? It means… when you start…. REALLY think about if it makes sense to use AO. Don’t just run into it…. think really hard, what are the implications? Write some test first code that has a few use cases to make sure it still makes sense.

So, listen to the AOP mentors (of which I am not one by the way!), not the people who jump on the bandwagon!

Of course, my little blog entry won’t stop anything.

As Mike Spille wrote:

When a novel technology just starts to come into common practice, there seems to inevitably be a cycle that has been repeated from time immemorial:

• Early adopters experimenting all over the map
• Said early adopters writing optimistic and enthusiastic articles about it
• “The masses” start to adopt based on the early adopter’s enthusiasm
• Early results are good, because people always start small and they benefit from the “low hanging fruit”.
• Over time, usage grows, complexity in usage grows, people start to see the downsides
• As more time goes by, people will write books like “Bitter AOP” and “Pragmatic AOP” and “AOP Sucks – The Case for Procedural Programming” :-)
• A few people will note that the gist of these books are issues that were obvious early on to the early adopters, but were suppressed and/or ignored due to undue enthusiasm or an unconscious need to suppress negative comments

Now I would temper one thing said. Said early adopters writing optimistic and enthusiastic articles about it. We have to listen to the folk who are really using it versus any ole early adopter.

I hope the mistakes are tamed a little this time around, and we don’t all start writing everything as an aspect.

Obviously it depends on your project, your thoughts on AO etc… however some have said that:

90% of code will be handled via OO. 10% of it can be more cleanly designed with aspects

NOTE: Again, just to make sure… when I talk about the AOP mentors I am thinking along the lines of these guys