I've been following with a lot of interest the The AOP caching challenge thread that Cedric Beust started 3 weeks ago with his post Aspectwerkz: aspects done right.
This led me to discover Renaud Pawlak's excellent JAC, and AspectWerkz, but I've been too busy with my real world job and well deserved vacations in the past few weeks to experiment with these or participate to the challenge.
Renaud Pawlak wrote a JAC Tutorial on Javaworld that I heartily recommend.
Hugo José Pinto wrote yesterday that: "Jonas Bonér points out the AOP stantardization project Renaud Pawlak started over at Sourceforge."
I look forward to participate in this AOPI - Aspect-Oriented Programming Interfaces project, which could become the J2EE of AOP, or at least the base for a future AOP JSR that Jame Strachan's suggested in Time for an AOP JSR?. Ted Leung argues that it is too soon for a JSR. Maybe, but the AOPI project can be a good start towards a standardization. I agree with as Jonas Bonér comment to Jame's proposal.
Seeing the heated discussions going around about implementing AOP in XML, in the language, or in a mix of the 2, I think discussing in the context of a federating open source project is a good idea to sort out the different point of views. I hope the JBoss folks will participate.
To come back to Cedric's The AOP caching challenge thread: I wanted to comment about 3 of his posts: More on caller pointcuts , AOP epiphany and Gregor Kiczales on the AOP caching challenge.
In More on caller pointcuts Cedric ranks Pointcut specification by complexity, "complexity being the amount of work the weaving engine has to do in order to produce the advised classes".
Caller pointcuts are the most complex since the weaving engine needs to classload all the advised classes and locate the call. He then suggests that IDEs that implement incremental compilation could do that, but it would be more difficult for automated build using ant.
So he suggests the following:
Of course, it would be quite overkill for both ant and the IDE to maintain their own "code repository", but imagine that just like they publish their plug-in API's, IDE's could also document their internal code repository so that ant could use it. How cool would that be?
Okay, my head is spinning now. I will get back to aspects very soon.
I think Cedric identified a real problem, and I agree with him that the next evolution will probably come through this sort of solution.
In AOP epiphany he quotes Booch "In the next two years or so I think aspect-oriented programming will bear fruit in testing, deployment, and business rules." and finds these estimates conservative.
Let's be realistic. Is AOP going to deliver all its promises? Or is it at least going to address these problems? I don't know. What I know is that some methodology will, because just like with the book of the Gang of Four, "once you go Design Patterns, you don't go back". But as of today, AOP is in a pretty good position to fulfill some of these goals, so I hope these early experimentations blooming left and right are just the beginning of a new paradigm shift in the programming world.
I wholeheartedly agree with him: AOP is just the beginning of a new paradigm shift.
Which leads me to the topic of this post: I had this "paradigm shift" feeling when reading a great book that I found when browsing books randomly in the CS section at the Stanford Bookstore in University last time I went to the US:
Generative Programming by Krzysztof Czarnecki & Ulrich Eisenecker.
I picked it because there was a section on AOP that seemed to cover more than just AspectJ.
Generative programming is described as: "A set of techniques that enables programs to be automatically constructed from smaller domain-specific programs. Generative programming brings the benefits of automation to software development" from Intentional Software's glossary.
I did not finish it yet but I was blown away by the ideas developped there: the same kind of feeling I had 5 years ago when I discovered the GoF's Design Patterns.
Here's a book review at the ACCU.
AOP is one of the techniques of Generative Programming, and seeing the flurry of tools and experiments that florish in the java community these days i think it's the first one we'll enjoy in our work lives.
But the most promising technology described in the book is something called Intentional Programming.
It is a project created by Charles Simonyi at Microsoft research.
Intentional Programming (IP) was a research project at Microsoft until spring 2001. In IP source code is stored in a hierarchical database were each node is an instance of a programming language construct. Programs can be edited using a structured editor with full graphics layout capabilities. An extensible compiler architecture enables the introduction of new user-defined keywords. There was also a work focus on representing traditional languages like C++ and Java inside IP.
The Intentional Software Corporation (intentsoft) is trying to evolve this technology developed by the Microsoft Intentional Programming Team into a shipping product.
This is not an open source project, there is no source code, not even some downloadable demo, not even any docs online. But the IP system and its design is very well described in the book and looks very promising.
The idea is that there is no textual source code, but an editor that lets you edit what they call "active source". Active source carries with it runtime methods to do the following: rendering of the code (to present it, type-in (to type or enter it), reduction (to compile it to bytecode, that they call R-code), debugging, editing and refactoring, version control.
What you edit then is not a text file but an abstract syntax tree (AST), ie the representation that your compiler would have of your text based code. This means that the costly parsing step of regular languages is removed, so is the need for IDEs to determine the structure of your code based on text files (the code repositories of current IDEs that that Cedric advocates should be shared by other tools).
But you edit it in a form that is domain specific: if I do math, I'll get a math formulas editor to edit my formulas, by importing the Math intention, but I can mix this code with some C or java code using the C or java intention. The good thing is that at debugging time I can inspect my Math objects at runtime, and not some obscure generated code, because debugging support will be provided by the Math intention.
This is a perfect environment for AOP, since AST nodes are perfect pointcuts, and in order to use them I just have to link to them at edition time.
I was very impressed by the decription of IP in this book. Then I did a little Googling to determine what had become of it, and found that:
The Home page of Intentional Software, the company he created to develop IP.
and more importantly, this press release on their web site: New Venture Set for Dramatic Improvement of Software Code
Bellevue, WA—September 17, 2002---Dr. Charles Simonyi, Distinguished Engineer at Microsoft and Professor Gregor Kiczales of the University of British Columbia today announced the formation of Intentional Software Corporation (ISC), a new company that will develop technology to greatly improve software development productivity by capturing the design intent clearly in the code. In addition, a licensing agreement with Microsoft has been signed that – in essence – gives Microsoft a “first right of negotiation” for developments in the critical early years.
...
Kiczales notes, “There is tremendous synergy between intentional programming and aspect-oriented technology. Working together, Intentional Software Corporation will be able to give developers some exciting, and very useful tools. Our AspectJ users are already asking for tools like these.”
I think it says it all: after creating AspectJ, Gregor Kiczales is going to implement the next paradigm shift with Simonyi at IntentSoft: what a dream team !
Which brings me back to Cedric's Gregor Kiczales on the AOP caching challenge: Kiczales thought experiment is very convincing to me, and I think outlines very well the drawbacks of the XML approach. Static Typing is a great advantage ... and by the way, it is at the heart of IP, where "anything you use has to be declared and defined somewhere" :-)
Thanks Cedric for asking the right questions: I always learn from your inquiries.
4:52:49 PM 
|
