Mixins and Traits (for Java)

I’ve read last night a post on traits for Java and I just thought to make a small comment.

According to the author:

The difference between a Trait and a Mixin is that order is important.

Well, in my opinion there is a much bigger, fundemental difference: mixins have state, traits don’t. When a class or object includes a mixin it includes all methods and attributes defined by the mixin, according to the Wikipedia:

A mixin can also be viewed as an interface with implemented methods. When a class includes a mixin, the class implements the interface and includes, not inherits, all the mixin’s attributes and methods.

This is quite an important difference, as traits are easier to be supported (except the inheritance change they are imposing), but the benefit is really limited. And the good news is that using AOP (e.g. AspectJ) you can have mixins (so implicitly you can have traits).

Posted by: Alex Popescu (aka the_mindstorm)

Advertisement

AspectWerkz enters a new level

AspectWerkz guys (Alex Vasseur and Jonas Boner) have announced the 1.0 final version. I want to congratulate for the long way they have gone and wish them to keep up the good work!
Congrats!
You can read about the current features and release notes while you download it.

Optimistical AOP

A few weeks ago a long discussion took place on the AOP is not here subject. Now, Bruce Tate expresses his leap of insight. In big lines, but with more style and tact than me, Bruce suggests that we must try it before saying it is not here. I agree with you Bruce! Every piece of good technology must be tried and given a chance before puting the stamp on it or screaming out it is not here.

New dynamic AOP framework

A new dynamic AOP framework was made public: JoyAop. I have quickly passed through the tutorial (while downloading it and so I might be wrong on what follows), and here are my impressions:

• being based on interceptors it only offers around advice
• offers the possibility of defining interceptor precedence
• pointcuts are defined using regular expressions or based on interface
• supports mixins
• aspect definition come in the form of an XML definition (a la AspectWerkz or JBossAOP)

.

AOP revisited

I have to add more reference entries for AOP from blogs of Adrian Colyer (AspectJ), Jonas Boner and Alex Vasseur (AspectWerkz). The previous are published here.

• Using AspectJ with Spring Adrian Colyer
• Spring and AspectWerkz – A Happy Marriage Jonas Boner
• AspectJ Hacks – #1 From System.out.println to switchable debug output Adrian Colyer
• Implementing caching with AspectJ – part I Adrian Colyer
• Implementing caching with AspectJ – part II Adrian Colyer
• AspectWerkz in WebLogic – domain wizard Alex Vasseur
• AOP in J2EE, Tomcat tutorial Alex Vasseur
• AspectJ and AspectWerkz compared… sort of… Val’s blog

Nice entries for AOP world

Today I have found two blog entries very interesting for the people playing or working or evaluating AOP. The first one came from Adrian Colyer (I hope you all know his involvement in AspectJ, appreciate you Adrian) and clarifies the configuration of pathes used by AspectJ. Paraphrasing Adrian I can say that after reading I have three friends standing there [AspectJ] for me.
The second one published by Jon Tirsen can be considered one of the best examples of AOP appliance. I heard lots of voices screaming about the lack of real examples. Here you have one that will proove AOP can take the weight out of your shoulders: undo action. I place it on my hall of fame examples for AOP near the Swing constraint verifier published by Ramnivad Laddad in AspectJ in Action (Ramnivas your book rocks!).
Damn …. I almost forgot the third one (you know: there were once two friends: Foo, Bar and Baz). If you are trying to evaluate which AOP-way you go today (SIC), check the JBossAOP vs Aspectwerkz.
The future looks bright!

marketing AOP

This (short) thinking process started when commenting on Cedric post: AOP Still Not There.
The first think I have in mind about this is: it is here, it is enabled to be here, but we are afraid of using it :-). Involving a new technology in your solutions is not an easy process, it must pass through different steps of beaurocracy, it must survive unaware critics, it must survive your real scenario. Moreover it must offer you a better solution. And I guess this is the criteria where AOP may fail :-(. I don’t want to be missunderstood! AOP will not fail the “better solution” criteria just because it is not best suited for solving a range field of problems, but because the war of acceptance takes place on wrong dimension. The tech guys fight this battle against the marketing, financial and management guys. It’s like saying let the tech guy sell some stuff. While they will be (maybe) able to present it from a technical point of view in the brightest colors and they may underline a full set of benefits, the other army has a way to large strategy/tactics to contra-atack. A short version of this fight would look like
Tech Guy: – Hey, I have analysed this problem and I consider that the benefits of adopting this solution will be outrageous. I do not count here the fact that the code will become clearer and more maintanable, but I see some oportunities in here to solve those damn issues we are facing for some time.
Others: – Hmmm…, ya, you are right. But how well do we know this stuff? Who are the supporters of this? (is there any giant company supporting this?)
Tech Guys: You know there are in fact some big supporters of it…
Others: Oke… let’s see. Why isn’t X offering a commercial solution for this? Why isn’t offering Y an integrated solution?
Tech Guys: (???)
Others: Oke… where shall we have to look for support? Any company offering trainings?
Tech Guys: The creators are doing a lot of good job, they organize all the time conferences, and presentations. Not to count some forums (…. on the other side: silent yakkkk) where they publish their knowledge
Others: Does our IDE support it?
Tech Guys: You know, there is some work to support this in [product] and they improve it all the time…
Others: we cannot shift all the dev guys to that product
Tech Guys: not all of us must use it, just those involved into this kind of tasks.
Others: Oke… do we have to buy some books on it? Are there any published?
Tech Guys: oh yes, it should be nice to have some, but in fact we can count them on one-hand fingers. But you know they are in fact really good and they help you a lot…
Others: … so we don’t have a real support for this. How it is supposed to solve some problems that may occur?
[… the discussion continues…. after some time]
Others: you know, shifting all of our dev line to this is not affordable to us. High risks are involved, and the support sucks. We cannot encourage you to go to niche solutions.
Tech Guys: … but it is not…
Others: Come back when you are able to show me a real solution. Thank you!

Concluding, I think that if we, the tech guys, are not able to adopt a solution or at least encourage it (finding best scenarios, telling the truth), the “others” will not jump to it. Passing around a full circle of fears, will not solve our problems and will not help good technologies to become big ones (large adopted).

AOP intro

A few introductory links on AOP.

• What is AOP? An introduction by Renaud Pawlak and the JAC development team.
• Aspect-Oriented Programming and JBoss by Bill Burke and Adrian Brock — Is aspect-oriented programming (AOP) the OOP of the oughts? It promises to apply common behavior across different object models. Bill Burke and Adrian Brock explore AOP by example in a JBoss application.
• Aspect-Oriented Refactoring Series – Part 1, by Ramnivas Laddad, author of AspectJ in Action
• Aspect-Oriented Refactoring Series – Part 2, by Ramnivas Laddad

I got two essential books on my library:

• Mastering AspectJ
• AspectJ in Action