Microsoft goes AOP?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

While AOP has reached a decent maturity level in the Java platform, thanks to several iniatives from different players with different priorities and goals (IBM, BEA, JBoss, Spring, and individuals like Bob Lee to name a few), Microsoft seems to be willing to move beyond that.

Last year at AOSD they were hosting a session on Phoenix, an interesting building block in the .Net CLR labs to help enable AOP frameworks. The community in .Net around AOP is fairly active as well, and Microsoft did awarded some of the projects, like Alan Cyment' SetPoint hosted on CodeHaus, the home of AspectWerkz.

Recently (Nov. 2005) Microsoft has set up a research event to emulate discussions around the best way to have good AOP solutions in the .Net platform. Several key .Net AOP project leads and folks from the AOP research academia were invited for a full day event at Redmond.

As far as I know Sun never set up such an event to try to understand AOP from its roots, and most of the discussion on the field has been driven by individual to individual networking and the AOSD annual conference.

I am eager to see where .Net ends up in that field in 2 years from now. There are certainly interesting architectures and concepts that we have implemented in Java based AOP that could be ported rightaway to .Net, though .Net luminaries have certainly several new ideas that 'd be worth exploring from Java luminaries point of view - and possibly standardizing on - obviously outside the JCP - unless Sun suddenly cares more about AOP.

Spring 2.x - innovation or maturity?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Last week I had the pleasure to discuss some more with the Spring team at JavaPolis, and I was thus given a quick informal update on what they are heading at in Spring 2.x, especially on the AOP side, discussing with Rod and Rob.

Spring AOP in Spring 1.x has been easy to use - though missing a good pointcut language. This simplicity is well described in a recent article on dev2dev by Eugene, and I had debated this issue and tried to solve it with Spring pointcuts on steroids with AspectWerkz.

In Spring 2.x, with the help of newly appointed excellent Adrian Coyler as chief scientist, my AspectJ lead peer, Spring AOP will unleash AspectJ and @AspectJ that I spent quite some time on this year as per our engagement to merge best of breed AspectWerkz with AspectJ.

But going beyond, Spring 2.x also introduces a way to define aspects in your spring bean xml files directly f.e.:









This is actually a really nice feature that I started playing with 2 years ago when implementing AspectWerkz with Jonas. So there is not much innovation there.

There might actually be some issues and hard work going forward. By having aspects defined this way, the AspectJ runtime that is used when your are using the excellent AJDT Eclipse Plugin for AspectJ will not take those into account (whilst regular @AspectJ ones are fully supported).

This means there 'll be definitely a need to open-up some more AJDT and have some extension point in it so that the Spring IDE can leverage it and have the AJDT crosscutting view display the Spring xml defined aspect.

Wups - xml defined aspect I have said - just like this June 2003' Jonas article introduces, back in AspectWerkz 0.6.3

Maturity - finally!