Section 5.5. LOOKING BACK

5.5. LOOKING BACK

It is quite interesting to look back to the period 19941997 and to compare my vision of AOP at the time with what AOP is now. My notion of Aspects^[2] was based on systems I had worked on or studied. So, back then, according to my "Separation of Concerns" report, Aspects, independent of the techniques used to program them, were things like synchronization, remote parameter passing, configuration issues, real-time constraints, object structure, failure handling, persistence, security, debugging, etc. When I went to PARC, I found out about run-time performance Aspects such as memory optimization, loop fusion, and evaluation time. Recently, I did a quick survey of what users are using AspectJ for by looking at articles in industry magazines [9, 20, 21, 44] and posting a question in the users list. The following categorization is an attempt at organizing my findings:

^[2] I am using Aspect with a capital A to denote crosscutting concerns at the conceptual (design) level, not at the implementation (AspectJ) level.

1. Debugging and instrumentation Aspects such as tracing, logging, testing, profiling, monitoring, and asserting. Most of the usages fall into this category, but some usages are very sophisticated. For example, one user reported having built a "virtual internal information bus" inside his company's application.

2. Program construction Aspects such as mixins, multiple-inheritance (e.g., for bean construction), and views.

3. Configuration Aspects such as managing the specifics of using different platforms and choosing appropriate name spaces for property management.

4. Enforcement and verification Aspects such as making sure the types of a framework are used appropriately, performing components' contract validation, and ensuring best programming practices.

5. Operating Aspects such as synchronization, caching, persistence, transaction management, security, and load balancing.

6. Failure handling Aspects such as redirecting a failed call to a different service.

The ability to use aspects as add-ons over classes, as well as to plug in and unplug different aspects with a compilation switch, is being perceived as the major advantage of AspectJ/AOP.

In retrospect, although we missed a few kinds of Aspects and mentioned a couple that didn't yet emerge in practice, the analysis that Walter and I made back in 1994, which was voicing a trend that was in the air, was a self-fulfilling prophecy! It is actually quite amazing that later we at PARC were able to design a language that supports this diversity of crosscutting concerns . . . with just a few key concepts. In other words, the path I had started onthe design of concern-specific languageswouldn't scale!

Another interesting observation is that AspectJ does not support any of the run-time performance Aspects that the group at PARC was focusing on before I joined. This doesn't mean that those Aspects are irrelevant; it simply means that AspectJ doesn't provide the kinds of referencing mechanisms that are necessary to support them.

One last comment on whether the broad AOP thesisthat it leads to better programshas been validated or not: I don't have enough data to be able to draw any scientific conclusion. My recent poking at the AspectJ users gave me anecdotal evidence, as some users described their systems and commented on their positive experiences. From where I stand now, which is relatively far from where I used to be, I can see that AOP is extremely popular. Maybe the academic thesis doesn't matter, as it never mattered for all other languages (Lisp, C++, Java, etc.). The academic thesis may not matter as long as AOP helps solving some practical software problems.