By Darryl K. Taft  |  Posted 2007-10-08 Print this article Print

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.

Darryl K. Taft covers the development tools and developer-related issues beat from his office in Baltimore. He has more than 10 years of experience in the business and is always looking for the next scoop. Taft is a member of the Association for Computing Machinery (ACM) and was named 'one of the most active middleware reporters in the world' by The Middleware Co. He also has his own card in the 'Who's Who in Enterprise Java' deck.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel