eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Father of AOP
Gregor Kiczales, a force in the creation of aspect-oriented programming, spoke with eWEEK Senior Editor Darryl K. Taft about the history and future of AOP.
Where did aspect-oriented programming come from? What is it?
If you look at the evolution from machine code to procedures like Algol and Pascal, to objects [object-oriented languages] like Smalltalk and Java, those are evolutions about helping architects and programmers structure complicated systems.
At the end of the day the systems are too big to think about them at the micro level. And aspect [AOP] is really just a next step in structuring mechanisms. Now you know objects didnt replace procedures; they just kind of gave a higher level structuring mechanism. And aspects dont replace objects; they just gave another kind of structuring.
And if you listen to what people say theyre doing with aspects, thats really what its all about. For example, when people say, “I can ship my system with six different logging policies,” what theyre saying is, “I was able to structure my system so that logging is a separate aspect of its behavior. And in fact I have six of them.”
So if you want to think about it in terms of structure or you want to think about it in terms of modularity, those are two ways of saying the same thing. And its really about saying, “Is my big, huge, vast system one big knot that I cant take apart and that I can only think about as one big knot? Or is my big, huge, complicated system a collection of subparts—some big subparts that have smaller subparts? And can I think about my system as saying, well, you know I can take this part out and put a new part in, and my system behaves a little bit differently but in a way I understand.”
So whats an aspect?
An aspect is a particular kind of part that has this notion of cross-cutting behavior. And the way to think about cross-cutting is it means that it affects lots of the systems activities. So if you have some enterprise Web application and you add a new field to the account record, then you know what thats going to do. Thats going to add a new field to each account. Thats a fairly localized effect. But if you say, “I want to wrap some security around access to all parts of all account records,” thats a cross-cutting effect in that it touches a bunch of things in a uniform way.
And thats what its all about. Its that systems have reached a level of complexity where we want to pull out those aspects.
If you look at enterprise Java, where its the first place that aspects are getting a lot of application, its exactly because the people making those kinds of systems are aiming to make various things pluggable. Like they want to make security pluggable. And by pluggable, I mean you want to be able to swap different ones in and out. They want to make persistence pluggable, they want to make logging pluggable. … And those are just classic aspects.
AOP brings power and simplicity to complex systems. Click here to read more.
Lets go back to the beginning. You were part of a team that created AOP?
Like all ideas of this kind, different groups in different places were kind of working in this space.
My group at PARC [the Xerox Palo Alto Research Center] is generally credited with having crystallized the simplest version of it, but there were other people who were right in the same space. There was a group at IBM—Harold Osshers group, for example.
But we had a group at PARC—myself and John Lamping were the principals—and we were trying to figure out expressivity. We wanted to write programs that were simple and clean, and what we had noticed was when you had these cross-cutting concerns, your programs werent simple and clean because you tended to have some code and then the same thing would appear in 22 different places. And every time the same thing appears in 22 different places, thats just a disaster waiting to happen. Because you might forget the 23rd, or somebody might decide to change something and only fix 21 of them.
And we kind of zeroed in on this notion that theres this cross-cutting structure, and we made this language that got a handle on it.
So, did you have a particular platform or environment in mind? Were you targeting Java?
We actually started prior to Java. And then we got ourselves to a place where we thought we understood what we wanted to do well enough that it was time to do a real version of it. And just at that moment in time Java was coming along, and we decided that Java was the place to do it. Because, since there was no legacy Java code, we felt people would be open to new ideas.
So we started AspectJ with Java in mind, and then AspectJ was kind of a restart of the whole AOP project for Java. But we already knew that the idea of AOP wasnt particular to Java.
What time frame was this?
When we started AspectJ, it was about 1998.
And when you started the AOP project in general?
It depends on how you count, but I think the first time we used the words “aspect-oriented” was 1995-1996. But wed been working in this space since about 1986 because we were doing reflection, but we decided that was probably too powerful for anybody to use, and certainly too complicated for a wide swath of people to use. It was because you could do this with reflection that we realized you could do it. And then the challenge was to then make it comprehensible.
Page 2: The Father of AOP
Reflection
So can you explain reflection?
You dont want to hear about that. [laughter]
Reflection is basically the idea that you have a system thats running and its allowed to go “meta” and start looking at the actual program. And once its looking at the actual program, it can change the actual program to do different things. Its an incredibly powerful idea. You can use it to do almost anything.
AOP is much, much less powerful than that. For one thing, you cant actually look at the program youre running. All you can do is say, When these cross-cutting things happen, do this. So its a much weaker version of the idea. But because its in some sense theoretically weaker, its practically much more powerful, because the theoretically more powerful idea is so powerful that nobody can use it because its so easy to shoot yourself in the foot. So that means that you would never let anybody but the absolutely most sophisticated programmers use it.
AOP is much less powerful, but because its less powerful its much easier to get it right. And most programming language research is like that. What you want to do is to say, “Im giving you enough power to get something done, but little enough power that its also predictable.”
So AOP is applicable to any language?
Its applicable to any object-oriented language or even non-object-oriented language, like plain C. So theres AOP for C, for Python, for Perl, for PHP, for Ruby, for Java, for C# and others.
Do you feel like its lived up to the promise?
Yeah, at this point I feel like weve been fantastically lucky. Its a once-in-a-lifetime project. In terms of practical impact … I have no idea whether in 10 years therell be AspectJ or a language construct called “point-cut.” But the idea that you can modularize cross-cutting things is here to stay.
So, who primarily would use AOP?
Almost all the enterprise app developers would use AOP. You cant use Spring without using AOP; you cant use JBoss without using AOP. So thats been the initial niche.
The chasm-crossing thing hasnt happened with AspectJ. Its not the case that all the Java programmers are using it, but a lot of sophisticated Java programmers use it. And a lot of Java programmers write their code and think aspects even if they cant use the real thing.
The chasm crossing might not happen until theres a whole new language that kind of has the support built in from the bottom up, although there are some people working on an aspect-oriented virtual machine. And if that comes along, then the chasm crossing might happen with AspectJ.
What are some of the new things going on with AOP, like Fluid AOP and HyperJ?
Well, the interesting thing about Fluid AOP is that in some ways its crazier and in other ways its much more conservative.
The AspectJ idea is you write a program that says, When these cross-cutting events happen, do this. The Fluid AOP idea says that you have an editor that gives you an editable view of your program that lets you say, pull together all the places in the code where this thing happens and let me edit them all at once. Thats more radical in the sense that the notion that youd twist your program into this funny new shape and edit it is different. But its more conservative in the sense that once youve edited the program its still a plain Java program.
One thing that makes it hard for some organizations to use AspectJ is that they have to use this new compiler—and a slightly new language. In this kind of world, one person uses this fancy AOP editor, but the program that everybody else sees is an ordinary Java program. That may be easier for some organizations to adopt, even though intellectually it seems more radical than AspectJ.
So how do you make it easier to adopt AOP? Are AOP programs harder to write?
There are some low-level tool issues that are absolutely important but temporary. So in order to use AspectJ in a production system, you have to deal with some of those low-level issues. And the problems there are all being solved, but theyre not all solved.
James Gosling [creator of Java] once told me that he thought that giving AOP to a typical Java developer was like giving razor blades to a 5-year-old.
Actually, I think that metaphor is wrong because what weve observed is that writing proper aspect code—writing the actual program is not that hard for people.
But I sort of know why hes touting the line that hes touting. Java has become a language that has a greater breadth and level of talent in developers than any other language out there. Most Visual Basic developers fall into one level of sophistication. Java has some programmers that are extraordinarily sophisticated, and the level goes all the way down to programmers who are much less sophisticated. And thats part of the plan.
And so Gosling has an extraordinary challenge when he stands up and talks. And Sun has an extraordinary challenge when they think about how to move Java forward. Its that some of the most sophisticated programmers are saying lets do this and this. And theyre right for a certain definition of right. And Sun is saying, “We get that and its good, but we dont yet know how to explain all of that to all these other people.” And some of the people at the high end tend to be some of the worst at explaining it because they tend to be derisive about all these other people. What I believe is that those people have other skills in terms of understanding the organization that these people dont have.
But Goslings trying to look out for all of these people, so he has to be conservative. And we dont yet know how to teach AOP to the less technically sophisticated people.
Why so long for adoption?
Remember, OO [object-oriented programming] started in 1964 or so, and prime-time OO started in the mid-80s. So AOP has gone much faster than that—about 20 years faster than that. Change takes time.
On the Java platform, where aspects are happening most is Spring.
What makes AOP better than OOP?
With AOP, you can take one of these cross-cutting concerns that cut across the structure of your system and make it into a module—an easy-to-identify part—that you can pull out and put back in. And that has tons of implications: It has product and architecture implications because it means you can make different variants of your product that have different versions of that module.
And you can invest resources in different implementations of a module and from a CTO [chief technology officer] perspective that lets you play with your architecture. So you can set groups aside to work on different strategies based on modules you can plug in. Thus, the fact that you can modularize these cross-cutting things can be a big deal. You cant modularize cross-cutting things in OOP.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.