Interview with the aspectj author
From: http://www.theserverside.com/talks/videos/gregorkiczalestext/interview.tss Translator: TAOWEN
Gregor Kiczales leads the development of AOP and AspectJ PARC team. He is a well-known AOP missionary and is committed to establishing a community that is also serving practitioners and researchers. He has been developing advanced programming technology and teaching these technologies to developers. He is a member of the ANSI CLOS design team, and is the author of the CLOS reference implementation, and "The Art of MetaObject Protocol" (MIT Publishing One of the authors of 1991). He is now in the University of Nserc, Xerox, British Columbia University Sierra System, where he leads his students in AOP, including operating systems, reconstruction, patterns, and new language structure applications, etc. aspect.
Dion: Tell us some historical things about AOP?
Gregor: AOP has developed from several different organizations. These studies include reflection, various tensions such as object-oriented programming, and the like. Early study - here I refer to the early 1990s - the promotion of the experience of the OOP construction system in the early 1990s, and it did beginning to see some OOP restrictions, in large systems, in the distributed system And in the system in the flexibility.
In Xerox Parc, I am very lucky leadership team, initially committed to reflex and MetaObject Protocols, which is now considered to be in OO programs, which is critical to providing some types of flexibility. Then we started researching the concept of Open Implementation, which is similar to what the abstraction of white boxes is now similar. In the end, we have come to AOP, where we feel that we have paid attention to a key issue, this problem is very common for the various techniques that make programmers modularize their code. We have been committed to AspectJ in 1997, the first release of the external users in 1998, and 1.0 Release is in 2001. Aspectj is funded by .darpa.
Dion: What is the meaning of cross cutting structure?
Gregor: It means that there are two or more structures (or decomposed), they can't load another one in another. If we look at this classic aspectj figure, we can see a structure, with black tag, which contains FigeleElement, Point, and Line; this structure is related to the status Elements status and drawing behavior. The second structure, with red color tag, including DisplayUpdating aspect; it is how the status of Figure Elements will trigger the screen refresh.
One aspect of SetX, Sety, Setp1, and SetP2 methods describe how to change Figure Elements in a Blagure Element structure. Other aspects of the same method are described in the Display Updating structure - they are all updated after being called.
(I know that this example looks slightly insignificant, and it is actually to track which Display is the display of Figements, but in this simple form, it does help us see what it means.) In the figure DISPLAYUPDATING ASPECT is a separate unit. But the same behavior cannot get Localized (locally) in a single black structure. Try to do this to force the code to achieve a behavior, this behavior is dispersed in all methods that will change the display status. We say that the status of Figure Element This focus and Display's update this focus on each other. The horizontal structure is different from the hierarchical structure. It is transformed into a different image of the system, not just remove the details to obtain more abstract views. Crossing is a deeper level than the code is decentralized. The disperse refers to a given one, and the code distribution of the focus is, such as the main graphical behavior and the inherent DISPLAY refresh behavior. The target of AOP is to allow modules (non-discrete) to achieve cross-cutting points.
Dion: What is the status quo of AOP?
Gregor: AOP technology and practice now has now turned from inventive stages. The new wave of people is invented invented and helped them get extensive adoption. Thus this is a great and exciting moment.
The invention is characterized by concerns that problems in practical applications, as well as many commercial speeds than general programming techniques. But of course, from the idea of innovators, any inventive stage looks slowly, and the new people are looking for an accelerated approach. As a community, we are looking for the first Killer Application of AOP. Many people bet that will be distributed enterprise applications.
Dion: What is the challenges you see in front of the development of AOP now?
Gregor: When answering this question, I think we can learn a lot through the history of OOP, especially the history of the 1980s. The first major challenge is to avoid excessive myth. We must be careful not to let us sound like AOP to solve all software problems. AOP is a modular technology - such as you have some good developers, they understand the problem to solve, AOP will help them develop better, cleaner, easier to reuse the code and easier. It is actually more than that, because we have learned OOP, a modular technology that can help us draw problems in the process. But AOP does not make all software simpler. It does not solve all modular problems. It is an important new tool in the developer toolbox to solve a class of software structures. We must be careful about this, onlyine, we will not see what is crazy roaring.
Another challenge is to confirm that we have no forgotten lessons. Whenever a technology is transferred from the inventive stage to the innovation stage, there is always a danger of some lessons in the previous stage. There is a natural trend for this happening because the innovator is re-created and re-packaged technology to serve specific techniques or special areas. I think the bridges that have been established between inventors and innovers are critical - once again, we can learn something from OO, OOPSLA conference is an excellent example of building such a bridge. I am willing to see the innovator and inventors actively communicate. Some trade-offs in the design of the pretext may not be suitable for today; but there are some key technical issues learned in the pretty stage should be inherited. I think we can learn a lot from this communication, and will truly help us progress faster.
Unfortunately, it is not that simple to build this bridge - I know that I have made some failure! The annual Aspect-Oriented Software Development meeting (http://aosd.net/conference) wants to patterize the OOPSLA mode, which is a good place to generate such bridges. The next spring meeting will have a Keynote speech made by Danny Sabbah (IBM Vice President, Development and SWG Technology, Application Integration & MiddleWare Division, Software Group). Because IBM is conducting a lot of investment in AOP, this speech should be very interesting. Another key place is that the AOP community should promote the traditional market, rather than competing with each other in the existing AOP users. Here, once again, you can look at the successful experience of the OOP community. In the early days of the OOPSLA meeting, there is a good effort for different language camps. That is to talk about what is its advantages about other OO languages, and promotes the general meaning of OOP better which OOP.
Dion: Many people seem to use the same system-level focus to talk about AOP (such as Logging, Debugging, Transaction Demarcation, Security, etc.). Can you give us an example of your concerns you encountered?
Gregor: The first thing I realized is that these concerns you mentioned are very important. But in order to answer your questions, in a specific system, there are still many other focus on the structure. Aspects can be used to maintain the intrinsic consistency between several methods of a class. It is ideal for enforcing a programming style of a contract. It can be used to force a variety of common coding habits. A large number of OO design modes also have a cross-cutting structure and can be encoded in a modular reusable form using Aspectj.
So use AOP to program the natural unit programming that simultaneously using Classes and Aspects as a function, and aspects and classes are true common concepts. IBM's Adrian Colyer, it is the leader of Aspectj on Eclipse.org, very good to this question:
When anyone first sees AOP, they see the examples and the type of interest they want to process tend to the core programs they are writing (or call non-functional if you prefer this word) Orthogonal. The classics we are talking about include Tracing, Logging, and error handling. In AspectJ's tutorial we sometimes call them auxiliary aspects.
When using Aspectj, use and too much OOP support mode, you will start not only to see the auxiliary aspects, but also the core aspect I am talking through your code. As far as I personally, I will even use aspect embedded in the class to process several methods of transverse this class (such as link acquisition and release in the database access class), which makes the intent.
At the AOSD meeting, Ivar Jacobsen made a speech that he explained the Uses Cases with cross-cutting structures - this is a key portion that makes them useful - and you can use AOP to modular implementation USE-CASES.
Dion: The difference between the tools look related to the woven and deployment.
Gregor: One thing happened in the innovation phase is that the trade-offs are re-considered under the limitations of the specific market considered by this technology. When we do Aspectj, we didn't consider the dynamic deployment of Aspects because we have seen some performance burdens, and we want to ensure that aspectj does not have any hidden performance burden. But now, at least for some applications, the power of AOP is dynamically deployed to pay this extra performance price. People like Mira Mezini are increasing the power of dynamic deployment to AspectJ, and most of the new frames, like JBoss, fully operated by dynamic deployment.
My feelings are the development of things, people will start focusing on performance. Aspectj has a good performance in static deployment, and the problem of static strong types of dynamic deployment seems to be handled, so we should be able to provide excellent performance in any AOP tool.
Dion: Do you predict that the future people use the tools that can be woven in the compiled period or the tools that are running at runtime? What is the standard?
Gregor: In the AOP methodology, the woven, which means that the cross-cut Aspect is tune with the remaining code. Thus it can be done by a pre-processor, a compile period, a compiled linker, loader, jit, or a vm.
The situation we are now is different from different times. Some new frames, like AspectWerkz and JBoss AOP, using interceptor to run at runtime. Aspectj is completely woven in the compile period or post-compile period.
When designing Aspectj, we work hard to isolate when weaving. Thus, aspectj is arrangement that can be woven in any period in any period of compilation period to VM support. I believe that as we have observed OOP in the past, this type of AOP will end in the form of developers. Therefore, I guess that users will provide different languages due to different tools, rather than they use certain tools in different times. In other words, the woven is a realization technology, like Method Dispatch (the translation: refers to the invoking function call), it should hide behind the scenes. We should choose the AOP tool for it (assuming a suitable implementation).
Dion: What do you think about whether to standardize?
Gregor: This is an interesting question. Java has done pretty well for itself following a rule of not including any new ideas in the actual language standard. By "new" here I mean that have not been in the innovation phase for some time). I think this kind of conservatism is a Good Strategy for Something with as Many Users AS JLS.
But AOP is no longer so new. The idea itself has been 8 years, and AspectJ has been 5 years of users. The core element is now stable for several years. At this point, I believe that a standard that can reduce unnecessary differences between AOP tools, and the space left to continue the experiment is a good idea to the community.
I think such a standard can at least two forms.
Aspectj is the current factual standard, and this becomes more and more shake. The community can see the core of AspectJ, and AspectJ's open source developers will agree to maintain them stabilize. AspectJ is now part of Eclipse means that it has continued support for it, so this is a good way to continue.
But some people have concerns about Aspectj, especially for dynamic deployment, changes in Java's syntax, and their dimensions. Therefore, another may develop an AOP core, which supports systems including AspectJ, JBoss, AspectWerkz, and even research. This core does not define any syntax, just the core of the core. First, in some form of drafts. It makes it possible to focus on efficiency, safety, etc. in a few years; at the same time, others can focus on how to build a programmer interface of this technology. Dion: What do you think is the relationship between metadata (JSR-175) and AOP? Can we define PointCut based on how the method is based on the method?
Gregor: It is very clear that it is very useful in ATTRIBUTE in AOP. Once JSR175 is released, I suspect that aspectj will at least be able to define PointCut based on Attributes matching.
As time development, we will learn when it is best to use Attributes-based Pointcut, when is the last use of other types of Pointcuts.
When using Attributes-based PointCuts, I want some subtle problems that we must solve in the future. Some of them have been raised on other posts of TSS.
It is clear that some style using Attributes is "Just Macros" or "Just Declarative Programming". Of course, this is not bad, but it may not provide all of our module. It may also make it difficult to use most of the most powerful features of AOP - PointCut.
I "think" We should be careful when using Attributes, let's describe the name of the attribute to describe "Pojd" (Plain Old Java Declaration), then define a constructor like advice telling what kind of aspect acts like that Attribute's Pojds. This is the left of the existing practice, now Attribute directly naming the aspect that should be applied.
Specifically, let us use the previous Figure. I believe we have written such a code (assuming the method in the class, Advice in Aspect):
@Changesdisplaystate void setx (int x) {this.x = x; }After (): call (@changesdisplaystate * * (.)) {Display.Update ();}
Not like this code:
@ UPDatedisplay void setx (int x) {this.x = x; }After (): call (@updatedisplay * * (.)) {Display.Update ();}
I believe that this better reason is that it is better modular with a crossed point. The focus in this code is "Change the method of changing the DISPLAY status). In the first code, this is modeled in the Advice. The second focus, "What method changes the Display status" all over the place.
In the second code, two payings are mixed together and are all over.
I believe that the benefits of following this style is that you get a more reused Attribute name - you are more likely to use existing Attribute in a good way in the new PointCut.
Also note if you don't have to take Attribute, like this:
Pointcut ChangesDisplayState (): Call (void Point.setx (int)) || ...; after (): ChangesDisplayState () {Display.Update ();} dam,! That We Have Some Learning to Do In Terms Of Guidelines for When To Use Attributes and when Not To Use Now, But ITS NOTY TO Send Out.dion: How to combine with each other?
Gregor: AOP complements the lack of OOP. AOP can make up other programming models, like process programming. But because OOP is the current mainstream model, most AOP tools are extension to the OO tool.
The AOP has added OOP to extension of Java (or .NET) with only a variety of AOP tools as Java (or .NET). It means that face-oriented programming practice has complementable object-oriented programming practice. A good OO developer learns AOP to be quite fast, because they have been cross-cutting with their own systems. These are also reacted in their work - for example, a good AspectJ program tends to 85% or more partial part of a good ordinary Java program.
Dion: Some people say AOP destroy the principle of OO modularity. What do you think?
Gregor: The modular principle is such things such as Textual Locality, Narraw Declarative Interface, smaller coupling, stronger consolidation. Appropriate use, AOP not only does not destroy these principles, but helps you reach these goals. To see why this is, you should look at the examples suitable for AOP, rather than ordinary OOs have produced a good modular example.
In an example in which the previous screen update can be used, the modularity of the normal OO solution can only be a compromise. The code that triggers the screen refreshed may be scattered into the Point and Line class. The code of this focus may not be locallyified, there may be no clear interface, may only be a textually couple, and may reduce the cohesiveness of the dispersed code.
If you write the same program with AOP, the module is better. The code that triggers the screen refresh has been locally, it has a declarative interface to the remaining code, which couples smaller, and all the code is more inner.
Of course, it is not impossible to write non-modular code with AOP. Of course it is possible. It doesn't mean that we should not do some work more simply produce more elegant AOP code (I mean using Private Fields like OO Accessor Rule).
But I believe what should be done is to provide the programmaking tools that can write more beautiful programs, rather than implying enough security mechanisms to make them can't write bad programs. Moreover, the programmer can use AOP to improve the modularity of modularity.
Dion: What do you think about AOP makes the program more difficult to understand?
Gregor: AOP makes the program more easily understood, not more difficult.
Again again, you should consider the examples of AOP, rather than OOP can produce good modular examples alone. Consider thinking from the trees to see this metaphor.
In a non-AOP program, you have a scattered implementation of a focus on the cache invalid, it is easy to read it from the line you are watching it makes the cache, there will be Call for some Invalidate method. But it is difficult to see the whole forest's look - the structure of the global cache invalidation can tell you how to do it, so that you can use this information to point out difficulties. In the aspectj program, the call to the cache invalid does not appear in the code it happens, but simple IDE support can give you a visual tip. There is a call. Therefore, in the AspectJ program, a simple program allows you to see trees. You can also browse Advice and Pointcut, clearly know the overall structure. Thus, Aspectj makes a complex part - the feeling of the entire forest - more obvious, more declared, clearer. Simple part - Trees - you can find simple discovery through tools.
Dion: It seems that the AOP supports whether the syntax of AspectJ expansive language or should be used to use a large amount of XML syntax as a tool such as AspectWerkz. What is your point of view?
Gregor: I think this problem has some emphasized. I don't mean this is not important; there are a lot of reasons. But there is no reason and the nature of AOP. For example, you can design an XML syntax with fairly simple syntax for AspectJ. The key issue of AOP is basically nothing to do with this grammar.
Dion: From what you seem to think why people think that grammar is so important? Is it the same as OOP, when people start, "I don't do it in C ..., I don't need another language"?
Gregor: I think this is very correct. For most people, they have a natural dislike to add some new things in the language for a while for a while. I think this kind of dishody may be just a good thing; I need to be very holding a language. But at this stage AOP is really no new, and AspectJ's design is based on years of experience and feedback from users. I think AOP will eventually be part of the language, not in the framework outside the language, but let everyone feel habits for this habit.
In addition to this type of conservative that I just mentioned, there is still a reason why people sometimes give it very terrible. Because it is a common voice, let me talk about it here. People sometimes say that the tools such as AspectJ learn more because it "needs to learn a new language, and the AOP frame is not needed." I think this is completely wrong - two tools need to learn a new sub-language. In the case like Aspectj, the sublaw is closely embedded in Java. In the case like AspectWerkz, the sublaw is encoded in XML. They are all Little Sub-Languages that developers must learn, and in the framework you must learn the framework API.
Your question fell to the 1980 OOP. At that time, some people thought that OOP should not be added to the language; an alternative to we should program it into the framework. In spring, this is mentioned in a discussion of TSS. I think the language is the correct direction for OOP, and I think it is also the same for AOP. But I also believe that some innovations currently around the framework are also valuable, because it helps us explore new design weighing.
And the additional benefits of language support is that something like Aspectj is actually weak than the framework like JBoss. Because it inherits some restrictions such as static strong types from Java. This form of functionality can actually make it a vast value because it enables IDE to provide some support, which makes it easier to understand the code is doing.
Dion: What changes occur when AspectJ is?
Gregor: Aspectj is now one of the Eclipse Technology PMC project, and IBM's Adrian Colyer has supervised the project's leadership in the developer community. This makes Aspectj to get long-term and robust development support, which is great for AspectJ users. 1.1 Release has just been released, and it has the functions of incremental compilation, which promotes the use of the large system; the texture code is woven, which makes it possible to use other Java compile periods; and support the Aspect library. The support of IDE has been greatly improved. Eclipse now comes from Aspect debugging, Inline Advice Annotation, and an advanced, allowing you to see the forest, how to cross the entire system for Aspects. Such feature is being developed like Aspect-Oriented Reconstruction.
Outside IBM and Eclipse, other vendors are also supporting Aspectj. Intellij provides an earlier version of their implementation, BEA also supports developers using Aspectj in the WebLogic program.
Dion: WHERE SHOULD People Go to Learn More About AOP?
Gregor: There are more sources of training and support all the time Tutorials are available at The Server Side Symposium, No Fluff Just Stuff, Software Development, OOPSLA, and of course AOSD conferences Many of these are focused specifically on AOP for enterprise applications.. .) There ispectj.
There are now consultants who provide training, mentoring, and design and implementation assistance. Some of those consultants can be reached through an informal consortium I set up called AspectMentor? (Http://aspectmentor.com)
Dion: Does developers should start to understand and use AOP?
Gregor: I think any developers who want to lead the latest technology should do this, there is no doubt, start to study AOP. What I learned in OO is that the earnings more, the sooner. AOP is like OOP, the true value is from the development of the entire product architecture to the development cycle. The more you start, the youngest, will be more than others. It is the best person to develop the Aspect library and the experience in Aspect library and Aspect design will have significant business value.
At the same time, I don't encourage people to be probably turned to AOP. Another thing we learned from OO is that the appropriate management of things to adopt is critical to reaching success with new technologies.
Dion: Do you think AOP will enter mainstream in a progressive way?
Gregor: It is important to use it. Developers are too busy, it is difficult to have time to understand this need to look from head, and you need to spend some time before you spend some time to explore these ideas.
For example, aspectj is designed for progressive AOP's careful wing. It reaches this purpose by supporting JVM compatibility, JLS backward compatibility, and tools like IDE and Javadoc extension. In addition, we have developed a phased adopted process in our five years we use aspectj. In this process, the first is the tool for the use of Aspects as a development tool, debugging, and enhanced test, or the internal contract check. Another scene is the prototype of cross-cutting points with aspectj, and once you understand the situation, manually put the code into the code, use the AspectJ code as a comment. This way in the development process uses Aspect enables developers to test Aspectj without persuading other people of the development team, or their boss.
After doing this for a few months, developers have two things: the ASPECTJ has achieved a better understanding, and the specific example of it can give them the specific value of the core foundation. This is the best moment attempt to convince the other people and managers, and start using Aspect in the sales product.
Dion: Do you think AOP will develop a revolutionary change like OO? Why?
Gregor: This is an interesting question. My answer is not. On the one hand, I think the idea of Aspect is deep in a sense than the object of the object. The object is a new way to draw a system into a hierarchical decomposition. They are similar in this regard.
But Aspect is about there are multiple, cross-cutting decomposition. It is very important to realize that the organization software structure is not necessarily a hierarchical idea.
But the industry is now more mature than in 1964 (innovation in 74, 84 and 94). Therefore, when we expect Aspect, there will be a major practical effect, it is difficult to say what it looks like more than 49 years ago.
However, it is clear that the ability to modular and cross-cutting points will have a big impact, not just in distributed enterprise applications, but also in other complex software we have developed. It improves the flexibility and quality of the software we develop and reduces the time and cost of development cost. It will also make software development more interesting.
