Section 6.1. ASPECTJ GOALS

6.1. ASPECTJ GOALS

The AspectJ project seeks to provide an aspect-oriented programming environment that is:

• General purpose

• Supported directly in the programming language

• Easy to learn

• Incrementally adoptable

• Easy to integrate with existing processes and tools

• Suitable for commercial use

6.1.1. General Purpose

AspectJ is designed as a general purpose programming language. It neither has specialized language constructs for particular aspects nor is targeted at a particular application domain (such as enterprise application development). AspectJ is general purpose in the same way that an object-oriented language such as Java is general purpose.

Over and above the forms exposed in the Java programming language, AspectJ lets the programmer express crosscutting concerns using aspects. The kinds of aspects that people write (or reuse) can be broadly divided into three categories: general-purpose aspects, domain-specific aspects, and application-specific aspects. General-purpose aspects are applicable to almost any program. Examples include aspects such as tracing, logging, caching, and pooling. Domain-specific aspects have broad applicability within a given domain. For example, aspects for transaction management, persistence, and security are specific to the domain of enterprise application development. Application-specific aspects are unique to the particular program under construction. In object-oriented systems, there are classes that fall into each of these three categories too, and just as there are many more application-specific classes than general-purpose ones, so there are many more application-specific aspects than there are general-purpose ones.

6.1.2. Direct Support in the Programming Language

A key decision in the design of AspectJ was that aspects should be first class entities in the programming language. In AspectJ, aspect is a keyword. One can create aspect types just as easily as class types. At runtime, Aspects have instances with their own state and behavior. The designers of AspectJ took the view that the best long-term strategy for aspect-orientation is to have the concepts directly represented in the programming language. This is in contrast to approaches such as Hyper/J [8], which work within the confines of an existing object-oriented programming language and have the programmer specify additional aspect-related directives in side-files.

Language shapes thought. The real power of aspect-orientation comes when a programmer starts to think in terms of aspects and to reason about a program using an aspect-oriented metamodel ("aspect-oriented thinking"). Aspect-oriented thinking is harder to achieve when you have an object-oriented language (and hence an object-oriented metamodel that structures your thinking), and you have to layer aspect notions on top of it. AspectJ lets you take a statement in the design document that "all SQL exceptions thrown by the data layer need to be logged for subsequent analysis" and encode it directly as:

 after() throwing(SQLException ex) : inDataLayer() {   logException(ex); } 

6.1.3. Easy to Learn

AspectJ is designed to be easy to learn. This goal led to the early decision to base the language on top of Java, a popular object-oriented language: Every legal Java program is a legal AspectJ program. When programming with AspectJ, a developer can use any Java class libraries, continuing to benefit from any prior investment made in learning them. The strategy is analogous to the history of C++, where expressing C++ as an extension to C built a bridge into the world of object-orientation for procedural programmers.

The AspectJ model adds aspect-oriented features to Java through a few additional constructs and retains a distinction between aspects and classes (aspects have powers that classes do not). A "more pure" or "stronger" form of aspect-orientation, in which everything is an aspect, was considered early in the design of the AspectJ language, but this proved to be too big a conceptual gulf for object-oriented programmers to easily cross in one step.

6.1.4. Incremental Adoption

AspectJ is designed to allow incremental adoption. It is important that users coming to AspectJ can take a few early steps without needing to make a big investment in the technology and concepts. Adoption of AspectJ typically proceeds in three phases. First, AspectJ is used to write simple aspects that police design and implementation constraints (for example, that only types in the persistence component should make calls to the database). These aspects introduce users to the notions of join points and pointcuts (see Section 6.2) but do not affect the compiled program or its runtime execution in any way. In the second phase of adoption, AspectJ is additionally used to write "auxiliary" or "infrastructure" aspectsaspects that handle things such as tracing, error handling, monitoring, and other concerns that are an important part of an application but that are not its reason for being. In the final phase of adoption, aspects are also used to help modularize the core application functionalityfor example, encoding business rules as aspects.

6.1.5. Easy to Integrate

AspectJ and the AspectJ tools are designed to be easy to integrate into existing environmentsthere is no requirement to throw everything away and start anew. The first important part of this is that the AspectJ compiler produces 100% legal Java bytecodes that can be run on any standard JVM.

The AspectJ distribution contains Ant [1] tasks that make it easy to switch an application build process from using the Java compiler to using the AspectJ compiler. It also contains the ajdoc tool that extends javadoc-generated documentation to include cross-references to aspects and documentation of the aspects themselves. As of the 1.2 release, AspectJ includes a simple API for integrating AspectJ's aspect linking (weaving) capability into an existing classloader hierarchy so that aspects from aspect libraries can be linked with application classes as they are loaded. AspectJ support is available in a wide range of Java programming environments, including Eclipse, JBuilder, NetBeans, and Emacs.

6.1.6. Suitable for Real Applications

AspectJ is intended to be used on real applications, not just for research examples. This requires a robust compiler that produces high-quality error messages, runs quickly with a small enough footprint, and produces quality generated code. This is also the reason that AspectJ provides features such as incremental compilation supportessential when developing anything other than toy examples.