By Michael Kleyman
When AOP is Used?
It is usually said that aspects represent
No clear definition of such a concern.
AOP can be dangerous when overused.
Calls, messaging etc. are the core concepts
Represented by classes, such as Call or
Billing is the crosscutting concern,
represented by an aspect.
Payment calculation initiated in advices to
methods of the core classes.
When AOP is helpful, but not
Corporate policies do not allow use of
experimental, immature technologies
An aspect allows rapid modification of
existing code, but the resulting program
structure is not the best possible structure
Crosscutting modification as opposed to
Example: Object Pooling
Goal: reuse objects instead of creating new
Can be represented by a factory class.
Introducing object pooling into existing
system is difficult.
AspectJ allows an easy but controversial
What is ACME
Convert AspectJ solution to pure Java
Prove of concept
Based on specific examples
Additional examples may be covered later
Java code must produce exactly the same
results as the aspect code.
Java code should not be significantly longer
than the aspect code.
The produced code should be easily
modified and used.
Key Goals (Continued)
The generated code must look similar to
code written by a human programmer.
Based on commonly used patterns and
ACME vs. AspectJ Compiler
Must not support the entire language
Must generate meaningful names (possibly
with user’s help)
May not use some complicated structures
used in the compiler.
Workflow with ACME
Implement the required modification using
Test the implementation
When the result is satisfactory, run ACME
to generate pure Java code with same
Creating Singleton Class
Aspect interacts with other code through
pointcuts on functions of a single class.
Aspect is converted to a class automatically.
All calls that are advised by the aspect are
replaced by calls to the singleton.
Example: object pooling.
Inlining Aspect Code
Aspect may be used to modify both
interface and behavior of an existing class.
Involves both advises and inter-type
Example: modification of the Point class.
Example: introduction of transactions
Add the member introduced by the inter-
type declaration to the class
Add a function for each advice
Replace all calls advised by the aspect by
calls to the new functions
Allow code reuse in several aspects
Typically involve abstract pointcuts and
concrete implementation of the advices
Transformed into hierarchies of classes
where the leaves are implemented as
When ACME helps?
Evolution aid: test before changing the
Eases adoption of aspect technology
Aspect represent crosscutting concerns
Aspects used as a configuration tool for
different application of the system
Type-dependent pointcut definitions
Implicit type casting
Compile-time applications of aspects, such
as “declare error”
More on execution join points
Require replacing the implementation of
functions, not the calls to them.
With inheritance require replacing several
functions for each advice.
Anything but the simplest around advice
must be transformed to very complicated
Very limited benefit
ACME was applied to Shay Raz’s work on
system scaling with aspects.
Some aspects required cosmetic changes
Some can not be processed because they
involve implicit type casting.
Possible solution: rewrite the aspects,
removing abstract pointcuts from the base
Built as an Eclipse plugin
Uses JDT library for Java source
There is no such library for AspectJ code
Parse the AspectJ files
Create new classes for “singleton” aspects.
Add new members to existing classes
Find advised function calls (using JDT)
Replace these calls by calls to generated