by by Jonas Bonér, Alexandre Vasseur, and Joakim Dahlstedt
Originally published on BEA Dev2Dev August 2005
Aspect-Oriented Programming (AOP) is gaining momentum in the software community and the enterprise space at large. Introduced by Xerox back in the 1990s, AOP has been getting more and more mature through several initiatives and innovations in the research community, the open-source community, and the enterprise arena. In the Java arena, open source has achieved great traction in the last two years, leading to the recent merger of AspectWerkz and AspectJ, now housed at the Eclipse Foundation with the code name AspectJ 5. AspectJ is sponsored by BEA Systems and IBM and can be considered as the de-facto standard for AOP in Java.
As the popularity of AOP is growing and the research community is moving things forward, vocabulary, concepts, and implementations have gained in consistency, allowing for better tool support and developer experience, such as with the AspectJ Eclipse plug-in AspectJ Development Tools (AJDT).
AOP has also gone through several implementation techniques, ranging from source-code manipulation to bytecode instrumentation—a technique widely adopted in Java, especially with the advent of the Java 5 JVMTI. This technique is now used by several AOP-applied, enterprise-grade products in the area of applica tion management and monitoring and has gained even greater popularity more recently with Plain Old Java Object (POJO)-based middleware and transparent clustering.
As a consequence, bytecode instrumentation is increasingly likely to be the thing you'll finally have to be made aware of, despite all the promises. Questions you'll have to answer include: Up to what point can bytecode instrumentation techniques scale and achieve manageability, transparency, and efficiency? Is there a risk that AOP implementations that rely on bytecode instrumentation will reach an endpoint that limits further innovation toward more efficiency, ease of use, and dynamism? Would JVM-level support for AOP solve these issues and to what extent? This article series aims to provide concrete answers to these questions by unveiling BEA JRockit JVM AOP support, as well as stimulating debate in this space.
This first article introduces AOP concepts and describes briefly why many implementations, for example AspectJ, are based on bytecode manipulation. It explains several limitations that are tied to bytecode instrumentation techniques and why they will affect both scalability and usability in the long run. The last section then introduces JRockit JVM support for AOP, which aims to address these limitations to provide an efficient backend for AOP and other interception mechanisms.
The second part of this article series will then unveil how far this support goes through concrete API details and samples.
Object-oriented analysis and design has given us tools to reduce software complexity by introducing concepts like inheritance, abstraction, and polymorphism. However, developers face daily problems in software design that can't be solved easily using object-oriented software development. One of these problems is how to handle cross-cutting concerns in the application.
A concern is a particular concept or area of interest. For example, in an ordering system the core concerns could be order processing and manufacturing, while the system concerns could be transaction handling and security management.
A cross-cutting concern is a concern that affects several classes or modules, a concern that is not well localized and modularized.
Symptoms of a cross-cutting concern are:
These symptoms affect software in various ways; for example, they make it harder to maintain and reuse software as well as harder to write and understand.
Aspect-Oriented Programming tries to solve these problems by introducing the concept of separation of concerns, in which concerns can be implemented in a modular and well-localized way. AOP solves this by adding an extra dimension to the design space, and introduces constructs that allow us to define the cross-cutting concerns—to lift them out into a new dimension and package them in a modular way.
AOP introduces some new constructs. The join point construct mirrors well-defined points in the program flow, for example, where a method is invoked or where an exception is caught. The pointcut construct lets us pick out join points that match certain criteria. The advice construct lets us add code that should be executed at matching join points. The introduction construct lets us add additional code to existing classes, for example, adding methods, fields, or interfaces to an existing class. Finally, AOP introduces the aspect construct, which is AOP's unit of modularity. An aspect is defined in terms of join points, pointcuts, advice, and introductions (also referred as inter-types declarations).