The 15% Solution

Though Gregor Kiczales wasn't party to the Palo Alto Research Center's flurry of innovations in the 1970s—GUIs, laser printers, Ethernet, the mouse and client/server architecture—he's well aware of the PARC predilection for not capitalizing on brilliant concepts. Kiczales, who's been a scientist at the think tank (formerly owned by Xerox) for 16 years, counts work toward the Common Lisp Object System among his contributions.

More recently, he's been speculating that aspects—code snippets that blithely cross class boundaries—might constitute a new programming paradigm as influential as objects. Though he lacks a university degree, he also heads research as a computer science professor at the University of British Columbia in Vancouver. What's got the development world talking now is Kiczales' latest project—er, product. It's taken only seven years (with heavy DARPA funding), he boasts, to go from the germ of an idea—aspect-oriented programming (AOP)—to a 1.0 release of AspectJ, an extension to Java that promises to conceptually consolidate a variety of tasks that are usually scattered throughout source code. We spoke with Kiczales about his vision for AOP at the PARC campus in January during a day-long AspectJ tutorial attended by 25 elite Java programmers.

Software Development: Describe the genesis of aspect-oriented programming.
Kiczales: A group here at PARC has been looking at ways to improve software architecture. For about 12 years, we've been thinking that crosscutting was "it." We first worked on reflection and metaobject protocols. That had almost too much power; people couldn't make effective use of it. Then, around 1992, John Lamping and I took another stab at how to capture crosscutting. Over a series of years, we developed AOP and AspectJ. A number of great people contributed along the way.

Who's on your team?
I'm the only original member. It takes one kind of person to go from this tiny bit of intuition to "Here's some stuff that sort of works." It takes another kind of person to go to a prototype, and it takes a third kind of person to make it real in Java. At each step of the way, we asked everyone to push their own limits: to start earlier and run longer.

What do you mean by that?
Start with an idea that is less clearly formed than you're normally comfortable with and take the idea more in the engineering direction than you're normally comfortable with. We've gone from research idea to 1.0 in an extraordinarily short period of time; that would normally take 15 to 20 years. I think we did it because everyone pushed their own limits so hard. Right now, the team is mostly people who would not normally characterize themselves as academic researchers; these people want users, not papers.

How will you spread the gospel?
We studied a lot about technology adoption, and one of the things that we worked very hard to do is take AOP, which I think is a revolutionary idea, and put it into an incremental package. Normally, when people have a new programming paradigm, they make a whole new language. But by putting it in Java, a Java programmer can become an aspect-oriented programmer in 15 minutes.

Our strategy is that you could start using AspectJ right away and you could start getting value from it right away. Local use of AspectJ will gradually become library use and then platform use. Basically, your use of it becomes more and more architectural, even though your first step was just a small one.

Gregor Kiczales, AOP pioneer, on the balmy PARC campus.

We've learned from other projects how new technology adoption can go well—and less well. For example, one thing C++ did right was that you could use it without telling your boss. We copied that—you can use AspectJ easily because fundamentally you're still programming in Java.

So the first piece is a smooth adoption profile. And the second piece is to do a lot of speaking in front of early adopter-style developers. Now, as we're starting to commercialize, we're basically going to do more of that, but in a more business-focused way. We're identifying the kinds of users and specific things that would give them the biggest bang for their buck.

In J2EE, this would come in stages. First could come performance tuning, distributed debugging and integration testing inside containers. Then would come extending J2EE support for persistence and authorization, error handling, metering, auditing, customization and enforcing business rules.

Are you courting open source folks?
Yes, by doing things like today's tutorial. This audience is the early-adopter Java programmer, the top third of Java programmers. You see the questions we're getting. Nobody here is saying "I don't get it" or "I don't believe it." The questions are all what [team member] Ron Bodkin likes to call "buy-in" questions: "Can it also do this?" and "How exactly would I do this?"
Our sales process has three stages. The first is to give the tool to the developer, then to the team manager, then to the platform architect. We speak to each of them in a technology-driven business way. This is a technology. It's not a brand play or a co-marketing play.

How do you undo aspects?
AspectJ makes your crosscutting code so clear that it's really easy to undo it by hand. On top of that, we support a mode that says, "Take my classes and my aspects, stick the aspect into the class and throw the aspects away." This is the golden parachute: "I don't want to use AspectJ anymore; put it in my code." No one has ever used it. Two years ago, people were a little bit more hesitant, working with a pre-1.0 beta-test technology with no support contract and with language semantics that were changing with every release.

How will you make money?
Selling support in the short term may not be a big revenue generator. Our first job is to enable customers to get real value out of this. That puts us in a consulting service model, although a consulting service model with a product. There would be an enterprise product, maybe a set of power tools, very good IDE integration and J2EE support.

Will you license the core technology?
We want the core AspectJ technology to be a public, de facto standard. Language plays don't work unless there's a standard. But we have ideas for refactoring tools that we would sell or license. If you look at the Java market, it's completely comfortable with the notion that the base language is a standard that's free. But it's also totally comfortable paying money for better development environments; better libraries.

Do aspects conform to the trend of raising the level of abstraction?
Yes, absolutely. In AspectJ you can express crosscutting structures in a modular way. We can say things like "anything that moves an object on the display" in a concise and high-level way.
Some efforts to raise the level of abstraction are generative or transformational in nature. In our approach, you capture the high-level structure in the actual code. There is no sense of "First, you translate it." I have a technical concern that transformational tools run into evolution problems, because people don't just draw the model, generate the code and then never change anything. They always want to edit the code.

AOP ideas can also apply above the level of the code, such as in designs or views on the code. We can use AOP techniques to temporarily pull certain methods together into one place—to take the existing modularity and stretch it so that you can see it in a different way, and then you can let go and it snaps back. That's what I call "fluid AOP." You can imagine doing fluid AOP on code or in UML.

Because AspectJ captures crosscutting structure clearly in code, the AspectJ development environment support helps navigate that structure. Here, the AspectJ support in JBuilder 6 is showing the programmer around advice on the fire() method of a spaceship class.

There's a whole group of people talking about this multifaceted view of the world. When Grady Booch wrote about this new vision ["Through the Looking Glass," July 2001], it was the result of a workshop that he, John Vlissides, Charles Simonyi, Ralph Johnson and I went to. The government was exploring big-vision software research to fund. Commercially, five years from now, it's hard to tell who'll be on top. But aspects are an idea whose time has come.

So you don't buy into the dichotomy of modelers vs. coders.
AspectJ today is at the code level, but I think the idea of aspects and crosscutting is at all levels. We decided to make our mark right now on code, but we're not intellectually or ambitionally restricted to that.

Have you seen other paradigms die out?
Well, Lisp is doing a little less well than it once did. Logic programming, rule-based programming, was going to be the thing that saved the world. It didn't. One important thing about programming in AspectJ or any of the other aspect languages is that you're still programming 85 percent objects. We're solving the problems that objects didn't solve. When we went from procedures to objects, we didn't throw out procedures. AOP proposals from other institutions also are careful not to throw out what's come before.

What kinds of problems have users had?
So far, the learning curve has gone well. Some people comment that whereas learning inheritance was hard, learning aspects was quite straightforward.

There is one classic bug that we have to fix. The way advice works is "in case this thing happens, then do this." But if you misspell the name of the moveBy method, say, then the thing you're talking about will never happen. The compiler won't tell you about that because it thinks, "I don't know; maybe they meant a method called 'moveBe'" and that's almost certainly a thing we have to fix in the tools. The fix is a lint tool that will read your code and politely say, "Technically, your code is correct, but often when you misspell the method name, it's not what you meant."

On the other hand, we've worked very hard so that you can write one aspect that knows about a bunch of classes, not all of which are necessarily loaded. So you might be naming a method that does not yet exist in this configuration. People who want aspects for product-line architecture need this.

What domains will adopt aspects?
Checkfree.com uses it in Web-based financial transactions. Some other people are looking at it in platform architectures. Sirius, which does service-level management software, is using it in production applications. Security looks to be a good application—not to replace the Java security framework, but in that framework, you end up having a bunch of places in your code where you call it, and AspectJ would facilitate that.

Are there plans to go beyond Java?
There's a project doing aspects for C++. At the University of British Columbia, I have a project doing aspects for C. An interesting question, of course, is "Will somebody do aspects for C#?"

Do aspects apply to procedural languages?
Yes. Because procedures have a structure and you can still need to crosscut that structure. At UBC we did it for C, primarily because we've been able to show some very nice results in operating system kernels, a performance-critical domain.

What's the team's process?
Until 1.0, we had the notion that there would be a release roughly every three weeks. We read through all the CMM stuff, and [team member] Bill Griswold helped us with our own little process that we follow. It's just the right size for three developers. We meet and everybody brings in a one-page contract that tells what they're going to put in the next release; we talk about it and everybody assesses whether it seems realistic; finally, we edit the contract and then we go. Three weeks later, we do the continuous process improvement thing: What did you actually put in the release? What was good and bad about the contract?

Plus, everybody's office is next to each other so you can scream down the hall. Of course, we do one-button builds and one-button tests.

What is your role today?
I've been the leader of the actual language design and the overall project leader. Jim Hugunin has led compiler development and overall tool architecture, Ron Bodkin is leading application architecture, and other members have led key subpieces. One thing we've learned is that timeliness is important. Unless the second-best decision is really lousy, the second-best decision made quickly is often better than the best decision made slowly. So when there's a disagreement, my role is often to settle it by making a quick decision.

What's your open source strategy?
Right now, we're the kind of open source project that says, "Don't worry, no one will ever hijack you; you can freely use this." We're starting to have external developers, but last year we were changing the language semantics on every release, and we didn't want external developers—and they wouldn't have wanted us.

How many users do you have?
We have more than 2,000 downloads a month, but of course downloads don't mean users. My gut tells me that we have 300 or 400 people who use it every day, which, given that we just went 1.0, is pretty good. And now we have had people approach us, saying, "Please sell me a service contract."

"I can't use it until I spend money on it."
Well, free software is hard to sell; people want more. Now that PARC has spun out of Xerox, we're offering consulting, training and support for commercial products and developing commercial products.

How steep is the AspectJ adoption curve?
I will argue that from the initial conception to users, we've gone faster than anyone before. Some people will look at the C++ curve and say, "Well, C++ grew faster," but all C++ did was put objects into C, and objects were invented in 1964. Crosscutting really came into focus around '91, and aspects didn't happen till around '94. So I think we're on a very fast curve. The real issue is, what will our post-1.0 curve look like?