July 30, 2004
Engine strip-down and rebuild
It all started so innocently.... bug #69319 "JDK 1.4 assertions cause VerifyError". VerifyErrors indicate one of two things - either a serious bug, or misuse of the -XnoWeave option (use -Xreweavable instead). This one was a real bug.
The test case was a pure Java program, and it looked unlikely to me that it would be a bug in AspectJ itself, so I ran the test case against the Eclipse 3.0 M6 compiler (which is the version inside AspectJ 1.2). Sure enough, it failed in the same way. Trying again with the Eclipse 3.0 final compiler, the test passed. So, the only way to fix this bug was to tackle a task I've been putting off for a couple of weeks - and upgrade the Java compiler inside AspectJ.
For those of you who aren't familiar with AspectJ's internals (I guess that's most of you...), the AspectJ compiler is built as an extension of the Eclipse JDT Java compiler. That gives us a good, robust, high-quality (ahem, apart from this bug.....) Java compiler as as starting point and avoids the AspectJ project team wasting precious resources building yet another Java compiler implementation. The Java compiler sources that we take from org.eclipse.jdt.core are in a carefully managed part of the AspectJ source tree. Moving to a new version of the compiler is analagous to doing a full strip-down and rebuild of a car engine....
I started by bringing across a copy of the Eclipse 3.0 final Java compiler sources. These are checked into the main tree, and then work proceeds in a branch (it makes subsequent merges easier when we come to upgrade the compiler again). Starting from the beginning - with the grammar files and parser, and slowly building up, I added back in all of the extension points that AspectJ exploits in order to add in its extra behaviour. We try and keep the changes in the actual Java compiler source as minimal and as clean as possible - while it's by no means as simple as a couple of well-defined interfaces, it's clean as it can be in the circumstances given that we stretch the compiler beyond its original design goals. With the base work done, the AspectJ compiler extensions can be layered in on top - carefully checking at each stage that assumptions which held for previous versions of the compiler are still true in the new version, and updating the code in places where the Java compiler interfaces have moved.
At this point in the process, the full AspectJ test suite will run (but probably not pass!). The final piece of the puzzle is to work your way through the failing tests (thankfully, the AspectJ test suite gives us pretty good coverage after several years of development), figuring out what's changed and why, and any implications that may have.
With all the tests passing, I checked the results back into the tree - major upgrade completed. This represents a big chunk of the work I wanted to do for a 1.2.1 release. I was so pleased with myself I forget to run the test case that started all this off in the first place - bug 69319. I only remembered as I sat down to write this blog entry. I just added it to the test suite and ran it. It passes, phew :)
July 29, 2004
Spring is here (again)
And you thought it was summer...
The Spring team just put out their 1.1 release candidate 1. I've been working with this from CVS head for a couple of weeks now (as a smooth project check-out and build process, especially if you are working in Eclipse, Spring is top-of-the-class) and the AspectJ support just blows me away.
I was working on a three-tier application, rich-client with a business middle-tier and a set of DAOs managing persistence. As you can imagine, plenty of aspects helping me keep it all under control. I drew myself an object diagram of the key runtime objects in the solution (some of them are aspects), and then was able to translate the diagram straight into a bean configuration file and move all of the configuration code out of the application. When you put the object diagram next to the beans.xml file, the mapping is just so clear - one of those magic moments in software development.
Here's a sample extract from the file that shows just how easy this now is...
... <bean id="businessRulesValidation" class="org.xyz.app.model.validation.BusinessRulesValidation" factory-method="aspectOf"> <property name="validators"> <ref bean="policyValidator"/> <!-- ... --> </property> </bean> ...
(BusinessRulesValidation is an aspect...)
Great job guys, thanks :)
A Tribute to Jim Hugunin
News of Jim Hugunin's move to join the Microsoft CLR team became public yesterday. Jim Hugunin led the AspectJ implementation team at PARC and played a huge role in making AspectJ the success that it is today. Jim is an extraordinary individual and it has been a pleasure working with him on the AspectJ project. He left behind very big shoes to fill when he stepped down as the AspectJ project lead and handed over to me. If I do half as well as Jim did in the role, I shall be very happy.
Thanks Jim for all of your contributions to AOP and to AspectJ - I hope we get to work together again some more at some point in the future.
July 22, 2004
Point and Counter-point
A week for the gurus to show their cards.... James Gosling comes out against AOP, and Grady Booch backs it.
Here's what James Gosling had to say:
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.
Not quite the line he took in the AOP panel at JavaOne I'm told. Since James doesn't give us any specific examples of the things he believes people are doing with aspects that are a 'really, really bad idea' it's hard to make a counter-argument. My experience and the experience of many people I've talked to is that there are plenty of perfectly sound aspects out there that improve the modularity and clarity of programs. Clayton Christensen tells us that the leaders of one generation of technology often are the ones that have the hardest time adopting the next generation. Is that part of what's going on at Sun? Pure speculation on my part.
I'm sure that a number of readers must be concerned about my safety after reading James' comments. I have been programming with AspectJ this week despite the health warnings, but rest assured I've got my safety helmet and goggles on (TSS cartoon anyone?).
Meanwhile Grady Booch gave a keynote at the Rational User Conference (one of our team, George Harley, was there too demoing AJDT), in which he predicted that...
...many of the frameworks of the future will be built upon UML semantics, and that aspect-oriented programming will be mainstream.
This is something I personally am becoming increasingly convinced of (as if I needed any more convincing ;). My reasoning is simple: there's a fast-growing ground swell of interest in aspect-oriented programming, and of the people I know that have tried AOP, once they've seen how it works their perception of programming changes and they never want to go back again.
Bruce Tate and Justin Gehtland have this to say about AOP in their recent book "Better, Faster, Lighter Java":
"It's my belief that new programming models evolve much more slowly than predicted. I also believe that once they succeed, they have a much bigger impact than we expect."
AOP has been quietly growing for a long time - the term aspect-oriented programming came into existence at PARC sometime between 1995 and 1996. AspectJ celebrated its sixth birthday earlier this year. Me, I'm looking forward to that 'big impact' :).
July 16, 2004
AJDT 1.1.11 Now Available
A major new version of AJDT, v1.1.11 was made available today. You can download it from the AJDT project page It's packed with new features: completely overhauled look and feel, much improved debugging support (you can breakpoint directly in advice), integrated ajdoc, new improved build configuration support and much more besides.
The team have put together a fantastic New and Noteworthy document that will give you a great idea of what's in the release - lots of screenshots too.
Here's just a small taster of the improved outline view and editor markers:
You really do need to check out theNew and Noteworthy.....
July 15, 2004
AOP courses in Vancouver, and in Europe.
I previously wrote about the AOP course that's coming up in Vancouver this September. Registration for the course is now open - see the course web site for details.
If you can't get to Vancouver, then there's now going to be a Europe-based offering too, to be held in Munich on the 4th-5th October. Early details are available on the AspectMentor site.
Gregor put together a great little section on "Industry and Press Trends on AOP" as part of that site, which I've reproduced here since it contains a lot of useful links in a very short space:
Industry and Press Trends on AOP(from the AspectMentor site) Aspect-oriented programming (AOP) is changing the way applications are developed. AOP increases the quality and value of your software design and implementation. AOP is getting increased industry and press attention, and has been identified as a "vital for our survival" by IBM V.P. Daniel Sabbah    . In addition to IBM, BEA, and JBoss are supporting AOP in their products  . Chief Software Architect Bill Gates recently said that Microsoft will adopt AOP.  AOP is a hot topic at developer conferences these days. At the recent JavaOne conference, the AOP panel session - featuring James Gosling and Graham Hamilton of SUN, Cedric Beust of BEA, and Gregor Kiczales - filled both its main room and its overflow room. At the Server Side Java Symposium, the AOP sessions were tied with the EJB 3.0 sessions for attendance. AOP was named by MIT Technology Review as one of the "ten emerging areas of technology that will soon have a profound impact on the economy and on how we live and work" .  The Server Side at AOSD 2004
 Java Developer's Journal
 IBM touts new 'aspect' for software coding, on CNET.com
 MIT Technology Review
July 14, 2004
I'm still here, Bill Gates likes AOP, and other stories...
It's been far too long since my last post, so I ought to explain myself. We're coming up to the manuscript delivery deadline for a book on AOP in Eclipse with AspectJ that we're writing with Addison-Wesley. I've been working 12-16 hour days writing in every spare moment, and the last thing I've felt like doing at the end of those sessions is, well, writing about AspectJ again.
Tonight I'm taking a breather :). So much has happened in the aspects world in the last few weeks, that I will use this post just to bring you (and me) back up to date).JavaOne
Of course there was JavaOne, and the infamous AOP panel. The session was absolutely packed, and got some good coverage in InfoWorld:
"If attendance at JavaOne sessions is any indication of what's on the minds of developer's then aspect-oriented programming (AOP) is a technology whose time is coming. At the show on Wednesday a standing-room only crowd numbering an estimated 1,500 people attended at least part of a technical session on AOP, a form of modular development."
I heard that the overflow room was packed too. Gregor gave a brief 10-minute mini-tutorial at the start of the session - so I guess that has to be the world's largest AOP tutorial to date.Bill Gates
Interesting quote from Bill Gates in the press this morning too. Microsoft has always been quiet about their views on AOP, but today Bill Gates is quoted by a reporter from ComputerWorld in NZ.
"...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."
We'll wait and see what that really means - I hope they don't try and claim that attributes on .NET are AOP and cause a lot of confusion. Still, Bill Gates is a smart guy and clearly AOP is making enough waves to get his attention so that can only be a good sign.AspectWerkz
The AspectWerkz team put out what looks to be a great new release of AspectWerkz, their 1.0 beta 1. Nice job guys.AJDT
One of the side-effects of working on the book is that we've made a ton of improvements in AJDT that will be available in the forthcoming 1.1.11 release - more on that very soon so watch this space, it's our biggest and best release so far by quite a margin.Books
Rod Johnson's "J2EE Development without EJB" book is finally shipping. I've got my copy on the desk here beside me. Also check out Bruce Tate's "Better,Faster,Lighter Java" - he has some interesting points to make about AOP.Spring integration
Still busy at work on this - Rod's being doing great stuff in the Spring CVS tree too. Here's what Rod has to say about it in a post on TSS:
"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."
Lots more stuff to talk about - more very soon I promise!