Jonas and Eugene from Terracotta - the Naturally Clustered Java provider and maker of OpenTerracotta - have published a very interesting paper on industry use of AOP and point out some limitations present in current AOP frameworks: "Clustering the Java Virtual Machine using Aspect-Oriented Programming".

Excerpt:
"application startup time with AspectJ load-time weaving [which I partly authored] was ... slower and memory overhead was ... bigger ... when comparing with similar transformations done with either the Terracotta runtime or the AspectWerkz AOP engine [which I authored with my friend and former coworker Jonas]."

This comes to no surprise to me as AspectJ is born for build time weaving and Eclipse integration and AspectWerkz was born for load time and runtime weaving. As author of both (as we joint forces from AspectWerkz to AspectJ back mhh.. 2 years ago) I was unable to get the best of both world in one engine as we initially focussed on features integration - such as thru the @AspectJ style that is annotation-defined and driven AOP. Since that time my open source bandwith has been drawned due to work engagements. That is unfortunate as I believe there are no technical reasons for this multi-weaving-optimized engine to not happen. Fortunately AspectJ is strong on runtime performance which is something you really have to consider as well.

Their paper is available online on AOSD 2007

While AOP has reached a decent maturity level in the Java platform, thanks to several iniatives from different players with different priorities and goals (IBM, BEA, JBoss, Spring, and individuals like Bob Lee to name a few), Microsoft seems to be willing to move beyond that.

Last year at AOSD they were hosting a session on Phoenix, an interesting building block in the .Net CLR labs to help enable AOP frameworks. The community in .Net around AOP is fairly active as well, and Microsoft did awarded some of the projects, like Alan Cyment' SetPoint hosted on CodeHaus, the home of AspectWerkz.

Recently (Nov. 2005) Microsoft has set up a research event to emulate discussions around the best way to have good AOP solutions in the .Net platform. Several key .Net AOP project leads and folks from the AOP research academia were invited for a full day event at Redmond.

As far as I know Sun never set up such an event to try to understand AOP from its roots, and most of the discussion on the field has been driven by individual to individual networking and the AOSD annual conference.

I am eager to see where .Net ends up in that field in 2 years from now. There are certainly interesting architectures and concepts that we have implemented in Java based AOP that could be ported rightaway to .Net, though .Net luminaries have certainly several new ideas that 'd be worth exploring from Java luminaries point of view - and possibly standardizing on - obviously outside the JCP - unless Sun suddenly cares more about AOP.

I am very pleased to announce the prototype version of JRockit that includes our AOP API is available. It will drive you far far away from current bytecode instrumentation techniques to a world of plain Java API, complete runtime control for hot deployment and undeployment, agnostic from the programming model you like for your aspects.

If you are involved in the AOP field, bytecode instrumentation field, APM field, and did not heard from us recently, please drop me an email and I 'll consider your participation in evaluating this technology to help us drive it to reality.

You can read the official announcement and some background information in our BEA dev2dev dedicated forum.

What if we simply think in terms of "is this type listening to locking events ?" instead of trying to come up with a pointcut expression that defines the semantics of a synchronized block - as done in Jonas discusion?

Lets draft some code:
Consider the program:

class Bar {
   synchronized void foo() {
      ..
    }
 
   static synchronized void statfoo() {
      ..
    }
 
   void stuff() {
       ..
       synchronized(bar) {
          ..
        }
    }
}

• waiting the lock
• just acquired the lock
• just released the lock (or perhaps about to release it - but this does not matter much for this discussion)

I argue that instead of defining semantics, the issue should be narrowed to a type pattern ie something as simple as Bar (or more fancy variations based on type hierarchy or annotation - you bet it).

Given that we can define this interface:

interface Lockable {
   void waiting();
   void acquired();
   void released();
}

As a user you can then implement this interface on your own types, use some sort of AOP or proxy to have it introduced where you want, etc.

So what should happen to make that work?

First based on the type pattern, we simply introduce Lockable to Bar. This can be done manually, by the mean of AOP if f.e. I was writing @Distributed class Bar { .. } and so on - depends on the use case.

Second the interface must then be implemented by Bar. The user can provide one if implemented manually, or the system (AOP f.e.) can provide an empty one ie something like (depends on the AOP system but you get the idea)

@Introduce("Bar")
class LockableNOOP implements Lockable {
   void waiting() {}
   void acquired() {}
   void released() {}
}

Last we need to transform the program so that the synchronized block or the Bar' synchronized method are triggering event to that. This is not that hard since we just need to look at the type hierarchy for non static synchronized method and given that an instance synchronized method can be rewritten (by the system) as a synchronized(this) block we end up to something like that:
Replace all synchronized blocks like that:
Given

synchronized(stuff) {
   ..
}

if (stuff instanceof Lockable) {
   Lockable lockable = (Lockable)stuff;
   lockable.waiting();
   synchronized(stuff) {
      lockable.acquired();
      ..// unchanged body
    }
   lockable.released();
} else {
   synchronized(stuff) {
      ..// unchanged body
    }
}

So far, nothing will happen, as we have a LockableNOOP implementation, unless the user (you) explicitly provided some implementation.

Last part: configure the system so that it advises Lockable' methods, so that you can add your behavior there (f.e. distribute lock, or trace them for some application performance system). There, usual AOP stuff can be used.
You can now access the enclosing static join point information if you need - which gives you if you really need it, the rich semantics Jonas was looking for: call(Lockable.waiting()) && withincode(....) && target(t) && cflow(...) ..... // t is the locked object

There are two interesting things to solve now:

• What if I want to kick out the synchronized() block ?(f.e. for distributed lock). I think a small variation of Lockable can solve that - f.e. boolean shouldUseJavaLocks(), and a tiny change for the transformed program.
• What about the static synchronized statfoo() {..} in Bar? For that one, the transformation would have to be a bit more compex so that we f.e. lock on an introduced static field. That said, the Lockable interface is not handy anymore. Any suggestion for that one? Should we define three methods like static void lockable_waiting() that ones would implement or introduce to adress this use case?

On a more high level perspective, this send us back to a recurrent set of problems in the AOP / bytecode transformation space:

• to achieve API transparency, we have a very intrusive transformation engine (though the one described here can be quite fast)
• by changing the bytecode we break the visibility another system may require to work properly (as f.e. we add if blocks, change synchronized method into synchronized blocks etc).

There is thus a set of open questions:

• So should that belongs to the JVM directly, and in which form? (as f.e. JVMTI already provides monitor entry / exit events, that should be fairly easy).
• Should those 3 Lockable' methods (or 6 if we include the static versions) belong to java.lang.Object direclty?
• Would an hybrid system that changes the synchronize blocks using bytecode transformation but then relies on JVM level support for AOP such as we do in JRockit be enough to listen for lock events?
• Is the cost of the introduced instanceof acceptable?

Happy thinking!

As you know we have been working on an API to add JVM support for AOP in JRockit. The prototype will be available any time soon.

The nice thing about it is that you don't manipulate the bytecode anymore and that you are using only well known java.lang.reflect.* API to tell the JVM if your pointcut is matching or not. This is somehow similar to what ones can do with Spring AOP - as this one is proxy based (see f.e. MethodMatcher API in Spring).

The immediate benefit of it is that first there is no need to have another in-memory representation of classes beeing weaved (before they get loaded) that is backed by some expensive (both memory and CPU) bytecode analysis. This advantage is detailled in our JVM support for AOP part1 article.
As a consequence it is really easy to query the method annotation, generics properties, and such - something that is extremely complex to achieve with acceptable overhead in regular bytecode based weaver such as AspectJ or AspectWerkz (actually more complex than changing some bytecode instruction).

So what is that idea I had ?
Having AOP support in JRockit is nice, but it will take some time before that gets mainstream (with eventually a JSR etc). In this transition period, there must be a way to implement a better bytecode based weaver that will perform way better than current weavers (both AspectJ and AspectWerkz), that will be easier to implement, and whose only requirement is Java 5 (well off course, it won't be as good as JRockit JVM support for AOP - so it is still a transition technology).

I have thus been sketching on an hybrid system that makes extensive use of the hotswap API, and whose actual weaver relies only on pointcut matching backed by the java.lang.reflect.* API ie does not build any kind of equivalent structure backed by bytecode analysis.
As such the memory overhead is zero, and the CPU overhead is way less than current AspectJ and AspectWerkz.

The overall idea is quite simple and consists in 2 phases:
Phase 1
A first weaver is changing the bytecode in some stable way - such that all classes are transformed (lets say prepared) the same way - while not introducing any dependancies on any kind of AOP, and while not adding any kind of performance overhead (ie no changes in the execution flow such as introduced by wrappers method and such usually used when implementing instrumentation needed for around advice).
All classes thus get loaded as expected with a very limited time overhead and no memory overhead at all (thanks to the excellent ASM performance).

Phase 2
Then when an actual class gets loaded (as per regular application behavior) I get a small callback invoked when this class has just been loaded and just before anything else happens (ie the class static initializer invoked by the JVM). Current load time weavers do things "just before the class gets loaded" and as such cannot access the java.lang.reflect representation of what they weave.
This callback can then perform the actual weaving by relying entirely on the java.lang.reflect.* API to match the pointcuts. It then constructs the instrumented version of the class and hotswap it thanks to the Java 5 API. The JVM eats this one and goes on.
The first prepare phase is needed as the hotswap API does forbids change in the schema (ie cannot add or remove methods or fields).

A nice extra side effect is that at any point in time any class can be exposed to the AOP layer thru a simple API. This can be handy for some cases where there are some circular references in the dependancies (f.e. the instrumentation needs the java.lang.reflect.Method class to match against the pointcuts so if I want to add aspects to the Method class, I cannot do it until I have a representation of this class ie there 's no way to have it working by simply invoking the callback from the prepared Method class itself).

This might seems like gory details, especially when compared to what we do in the JRockit JVM support for AOP, but I am sure there are some concepts worth digging there - as memory usage and weaving overhead as been reported more than once as a major problem (see f.e. use case with AspectJ reported by Ron Bodkin where the system takes 4 minutes to start instead of less than a minute without any weaver here)
This makes it also very easy to add aspects even to java.* classes (though it's not generally a good idea unless you know what you are doing).

This sample is an actual code snip of the actual AOP transformation (part of phase 2). As you can see it relies on the java.lang.reflect API.

    public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {
         if (!filter(access, name)) {//fast filter for f.e. clinit method as we look for method execution join points
              // see if we get a match for this join point
              // only java.lang.reflect.* API is used here
              Member method = ReflectQuery.getMethod(m_klass, name, desc);
              Class thisClass = m_klass;
              Class targetClass = null;
              Member withinCode = null;
              //do matching
              if (match(method, thisClass, targetClass, withinCode)) {
                   //change the bytecode but don't change the schema for hotswap purpose
               } else {
                   return super.visitMethod(access, name, desc, signature, exceptions);
               }
          }
     }

Finally I must say this idea is not 100% new as I wrote a paper on it for AOSD 2004 (read my paper here). At that time though I was not doing the pointcut matching based on the java.lang.reflect API - as the purpose was to enable dynamic AOP in AspectWerkz 1.0) ie I was not solving the problem of the memory and CPU overhead of the actual weaver.

What do you think? Are those ideas worth digging more?

We have plublished a follow-up to our JavaOne 2005 session that describes with some more details the JVM support for AOP that is beeing designed within the BEA JRockit JVM.

This first article introduces the problems that usually happen with current weavers (in the Java land) and briefly described the proposed solution.

The next part to appear in the following weeks will give more details and code samples.

Read the article

JRockit JVM Support For AOP, Part 1 by Jonas Bonér and Alexandre Vasseur, Joakim Dahlstedt -- AOP is all the rage, but how do you implement it? In this article, Jonas, Alexandre, and Joakim show that the current approaches to implementing AOP suffer from many problems, making scalability an issue. Moreover, they indicate that the traditional approach to aspect weaving duplicates efforts that the JVM already performs.

We are currently working on making the prototype implementation available for further evaluation.

If you could not attend JavaOne 2005, the slides are available from the JavaOne web site, and they are also available here

The full webcast of the JavaOne session is also available on dev2dev.

**** Introduction

As development of AspectJ 5 and the merger with AspectWerkz making good progress, several users have started to wonder how the load time weaving under Java 1.3 / 1.4 VM be enabled.

Despite the name, AspectJ 5 is not at all tied to Java 5. I have already explained in this post how to write plain Java aspects using JavaDoc annotation and Backport175.

In this post I 'll explain how to enable load time weaving for Java 1.3/1.4 for AspectJ... by using AspectWerkz ! ie that AspectJ will sit on top of the very low level layer of AspectWerkz.

**** Some background

In AspectWerkz we enable load time weaving to happen thru a wide range of options that user can choose:

• Java 5 agent
• JRockit specific integration with JRockit agent
• bootclasspath family
• hotswap family

When running Java 5 or JRockit (java 1.3 / 1.4 / 1.5) you don't need to read further and can stick to what's provided out of the box in AspectJ 5. Else... continue reading.

The AspectWerkz low level layer named aspectwerkz-core is actually a generic load time weaving layer. It comes with one interface that one has to implement - very similar to the JSR-163 instrumentation agent: the org.codehaus.aspectwerkz.hook.ClassPreProcessor.

This core layer comes with a set of tools that allows to turn this one on into the environment. The most easiest to use is what we called the "prepared bootclasspath" where you basically run a little script that will patch the java.lang.ClassLoader to hook in the agent, and will give you back a jar. This jar file can then be used first in the classpath when you start your JVM so that the agent gets called.

You can read more about all the options in the AspectWerkz doc here.

**** Running AspectJ by using AspectWerkz for load time weaving

I describe here the implementation of the agent, but you can use directly the one I ship with this post if you are not interested in the details. You can assume this one is LGPL, as AspectWerkz is.

The implementation of the ClassPreProcessor to use AspectJ on top of AspectWerkz core is straightforward and looks like that:

package org.aspectj.ext.ltw13;

public class ClassPreProcessorAdapter implements
// implements the AspectWerkz core interface 
org.codehaus.aspectwerkz.hook.ClassPreProcessor {
 
     /**
      * Concrete preprocessor we delegate to
      * This one sits in org.aspectj.weaver.loadtime.*
      */
     private static ClassPreProcessor s_preProcessor;
 
     static {
          try {
               s_preProcessor = new Aj();
               s_preProcessor.initialize();
           } catch (Exception e) {
               throw new ExceptionInInitializerError("could not initialize preprocessor due to: " + e.toString());
           }
      }
 
     public void initialize() {
          ;
      }
 
     public byte[] preProcess(String className, byte[] bytes, ClassLoader classLoader) {
          // skip bootCL
          if (classLoader == null) {
               return bytes;
           }
  
          // skip AJ weaver well know stuff to avoid circularity
          if (className != null) {
               String slashed = className.replace('.', '/');
               if (slashed.startsWith("org/aspectj/weaver/")
                   || slashed.startsWith("org/aspectj/bridge/")
                   || slashed.startsWith("org/aspectj/util/")
                   || slashed.startsWith("org/aspectj/apache/bcel")
                   || slashed.startsWith("org/aspectj/lang/")
               ) {
                    //System.out.println("SKIP " + className);
                    return bytes;
                }
           }
          // do the weaving using AspectJ weaver
          return s_preProcessor.preProcess(className, bytes, classLoader);
      }
}

By using the AspectWerkz Plug utility we generate our load time weaving enabled java.lang.ClassLoader in awaj-boot.jar (see AspectWerkz doc for other options, that might be more license friendly if you care). This can be done thru Ant:

        <java classname="org.codehaus.aspectwerkz.hook.Plug" fork="true" failonerror="true">
            <classpath>
                <pathelement path="${java.home}/../lib/tools.jar"/>
                <path refid="aw.path"/>
            </classpath>
            <arg line="-target _boot/awaj-boot.jar"/>
        </java>

The last step consists in starting the JVM with this one, passing in a specific option to say what is the ClassPreProcessor implementation we want to use (the default one beeing AspectWerkz). Starting a sample with Ant will thus looks like this - the important details are int he jvmarg option

    <target name="test" depends="compile.test, compile, prepare">
        <java classname="test.ltw13.Sample" fork="true" failonerror="true">
            <classpath>
                .....
            </classpath>
            <jvmarg line="
      -Daj5.def=test/aop.xml
      -Xbootclasspath/p:_boot/awaj-boot.jar
      -Xbootclasspath/a:D:/aw/cvs_aw/aspectwerkz4/lib/aspectwerkz-core-2.0.jar
                         -Daspectwerkz.classloader.preprocessor=org.aspectj.ext.ltw13.ClassPreProcessorAdapter
            "/>
        </java>

****  Sample project

I am attaching the complete source code, along with a sample Aspect in a zip.

This sample further use Backport175 so that the project is 100% Java 1.3 - without any of the AspectJ specific extra keyword to defines aspects that would disturb your regular javac compiler.

Off course, this load time weaving can be used for any kind of aspects, so adapt it for using AJC if you have some .aj files to compile.

Note: this zip does not include AspectWerkz jars, Backport175 jars, and AspectJ jars needed. You will have to get those and fix the Ant build.xml for your environment. See the build.xml file in the zip. (the sample is also refering to AspectWerkz 2.1RC1 - so change it to AspectWerkz 2.0 / sorry about those minor details).

It may also happen that you will need a SAX XML parser has Java 1.3 does not ships one. You may read more about that in the AspectWerkz FAQ for example here (read "Does AspectWerkz support Java 1.3?"). This is not contained in the sample project neither.

Get AspectJ load time weaving on Java 1.3 enabled by AspectWerkz !

You will need AspectWerkz 2.0 for it. Get it there.

To run the sample, you will also need AspectJ and Backport and the Backport175 AspectJ extension. See build.xml on how to get those.

When turned on using any kind of compilation/weaving mode (compiling with ajc, within Eclipse AJDT, doing bynary weaving, or using loadtime weaving), each weaved class keeps track of

• the aspects that are affecting it
• its state before the weaving happened (ie its bytecode without aspects)

This option is very handy when you plan to weave more than once your application (because f.e. this is a library that you distribute), and when you want to make sure everyone will be able to add some more aspects in there.
Actually, discussions are taking place if this should be the default.

An interesting consequence is that it is fairly easy to implement an opt-out AOP engine that simply restores the state prior to weaving, and thus kicks out all the aspects from the application !
There are of course realistic use-cases for it :

• sanity check if production is very scared about use of AspectJ, knowing that the developpers team is using it for their own needs (declare error / warning f.e. and tracing in QA stage etc)
• obtain some more info about which aspect is in, and is affecting the application, to increase the trust everyone gets in using the technology
• introspect some third parties libraries and see if they actually use aspects
• add some more reporting features on the go, to be able to have at any time the list of aspects that are in the system f.e. thru some sort of web console
• enforcing that some key section of the system are not allowed to be advised by anything, or only by some sort of well know and certified aspect(s)

A small amout of code is required for it, the trick is mainly to add another Java 5 agent or loadtime weaver that will check for this reweavable state and do the reporting.
This is actually very easy to do when using f.e. AspectWerkz-core as the backend to hook this one in and have it work as well on Java 1.3, and using ASM for the bytecode details.

Here is a sample output (I am using AspectJ loadtime weaving to do the weaving first, but that could be done using post compilation with AJC, or compilation from within Eclispe AJDT etc)

// in this sample, start the app with AspectJ loadtime weaving (could have been compiled with ajc instead)
// and pipe with the UndoAspectJ opt-out engine using the AspectWerkz core
// as a backend
#java -javaagent:aspectjweaver.jar -Daj5.def=test/aop.xml
       -javaagent:aspectwerkz-jdk5-2.0.jar
       -Daspectwerkz.classloader.preprocessor=
          org.aspectj.ext.undoaspectj.ClassPreProcessor
       test.undoaspectj.Sample

weaveinfo Type 'test.undoaspectj.Sample' (Sample.java:28) advised by
   around advice from 'test.undoaspectj.Sample$TestAspect' (Sample.java)

// here is the opt-out message
UndoAspectJ - test/undoaspectj/Sample was affected by 
	test.undoaspectj.Sample$TestAspect

// execution without any aspect takes place:
Sample.target

// without the opt-out we would see the aspect executing:

weaveinfo Type 'test.undoaspectj.Sample' (Sample.java:28) advised by
   around advice from 'test.undoaspectj.Sample$TestAspect' (Sample.java)

// execution with aspect takes place:
Sample$TestAspect.around
Sample.target

Though the first idea is quite odd and counter productive, this illustrates that ones could easily implement a security layer on top of AspectJ without even going deep in the AspectJ code base, to enforce security constraints about the use of AOP in the system and in the deployments at large.

So is opt-out AOP good or evil ?

I am happy to announce that the @AspectJ support within Eclipse AJDT will appear in the next build snapshots, ie very soon !

That is an important step that brings to the AspectWerkz and AspectJ merger all its meaning, by providing a plain Java syntax (based on annotations) to write AspectJ aspects (aka @AspectJ) while still providing excellent support for it in Eclipse AJDT plugin - just as it exists for the well know AspectJ style (code style).

In the list of things to already expect, that will officially ship as of AspectJ 1.5 M3 in the following days:

• error checking for pointcuts (even though those looks like strings within an annotation)


• warnings when @AspectJ annotations are misused (f.e. used in a class that is not annotated with an @Aspect annotation etc)


• advised by view


• advises view and cross-reference view


• and off course AJC integration (ie weaving happens behind the scene as compilation is done)

As a world premiere, here is a snapshot of an @AspectJ aspect in AJDT !

For those of you using AspectWerkz, you may wish to give it a try very soon, as it is already much better that the Eclipse plugin I had written for AspectWerkz, and as it will help you to get started with the @AspectJ syntax in your favorite IDE.

Start your download engines to get the next build snapshots and the upcoming AspectJ 1.5 M3 with your fresh Eclipse 3.1 final !

(Many thanks to Andrew and Mik for answering my questions to get that bits working)

The @Aspect style is also referred as @AJ, or annotation style, or this way to write aspect with annotation that we came up with thru AspectWerkz. It mainly means that AspectJ allows you to write an aspects using wether the well known code style or the AspectWerkz like annotation style.

// code style
public aspect SomeAspect {
      void before() : execution(* Foo.bar()) {
          // do some stuff
          // use thisJoinPoint etc
       }
}

// annotation style, here with Java 5
@Aspect
public class SomeAspect {
      @Before("execution(* Foo.bar())")
      void before(JoinPoint thisJoinPoint)  {
          // do some stuff
          // use thisJoinPoint etc
       }
}

And since Backport175 brings annotations to Java 1.3 while preserving the bytecode format that the Java 5 specification describes, it seamlessly allows you to use the very same AspectJ version to write @Aspect on Java 1.3 as well (but please don't call it the doclet style!)

// annotation style, backported to Java 1.3 or 1.4
/**
 * @Aspect
 */
public class SomeAspect {
     /**
       * @Before("execution(* Foo.bar())")
       */
      void before(JoinPoint thisJoinPoint)  {
          // do some stuff
          // use thisJoinPoint etc
       }
}

For the Java 1.3 to work, you just need an single little jar that contains the AspectJ defined annotations (like @interface Aspect ) backported to Java 1.3 in the form of regular interfaces (ie interface Aspect ) and then make sure you have those classes first when doing the weaving. Aside, since AJC (the AspectJ compiler) is not yet integrated in the doclet parsing pipeline, you need to follow a binary weaving strategy ie:

• develop the aspect and the application with Java 1.3 (remember it's plain Java so you can use IntelliJ if you want)
• compile the sources with regular javac
• post-compile with Backport175 to handle the annotations
• binary weave with AJC
• run

That sounds a bit cumbersome but some simple Ant script is of great help. Aside Backport175 comes with plugins for Eclipse and IntelliJ so you end up with just the binary weaving step - that is rather common.

I have made this little AspectJ extension available here (that can be used with Java 1.3)

You can also grab the source code for it, that includes a small demo here.

Just set aj.root in the build.properties to the folder that contains aspectjrt.jar and aspectjtools.jar from a recent nightly build (will work for M3, does not for M2, so use a recent one!). Then run ant clean test .

Check the build.xml file to understand how the different build steps are performed.

In the IDE it will also popup pretty well. See for example the little green @ signs in the margin in this IntelliJ screenshot.

So now we have AspectJ @Aspect straight in IntelliJ. Off course, you'd better use Eclipse AJDT to benefit from the rich user experience that it provides when dealing with software modularity thru AOP and AspectJ.

Using Backport175 also allows to use custom annotations in the pointcuts under Java 1.3 to define stronger contract between the aspect and the application, as Adrian describes here as the Holy Trinity (when you further add dependency injection) (the demo don't include that but I let you try it).

In a follow-up post I will also explain how the new AspectJ enhanced load time weaving ala AspectWerkz can work with Java 1.3 and 1.4 as well - since it has been a recurrent question.

JavaOne 2005 will be a good opportunity for you to have an update on the
AOP field. Last year we presented AspectWerkz plain Java AOP and its
J2EE integration facilities. This year, several sessions will include
AOP related sections and give testimony of interesting use cases, and
as Jonas recently announce we will for the first time present
the JRockit JVM support for AOP.

Make sure you attend this technical session on Tuesday June 28 (TS-7659, "Runtime Aspects With JVM Support") and have a
sight at what's next in the AOP galaxy. If you can't make it, visit us
at the BEA booth where we will be eager to show you the JRockit JVM
AOP support thru live demos.

You can also visit us at the Eclipse booth where we will show latest
AspectJ 5 and AJDT versions. This includes plain Java AOP and
load-time weaving ala AspectWerkz that I have been working on for some
month since we merged with AspectJ, and many new things regarding Java
5 support in AspectJ 5 (annotation matching, generics etc)

Meet you there !

Three months ago when we wrote the AWBench AOP benchmark suite, I had to hack some little Spring AOP aspect and pointcuts.

If you are familiar with Spring and know about AOP (AspectJ, AspectWerkz, JBoss etc), you know that Spring pointcuts are rather ... well sadly un-intuitives.
They might be for new users, but not anymore when you have very basic AOP knowlegde, and you are more and more !

I could not resist and integrating Spring with AspectWerkz pointcut (yes, once again for the third time, after the Spring container Jonas did and the extensible container we shipped.)

A Spring pointcut before the wedding with AspectWerkz - almost impossible to combine with other patterns unless you have your "Mastering Spring XML" in the pocket...

    <bean id="theMethodExecutionGetTargetAndArgsAroundAdvisor1"

        class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">

        <property name="advice">

            <ref local="theMethodExecutionGetTargetAndArgsAroundAdvice"/>

        </property>

        <property name="pattern">

            <value>.*aroundStackedWithArgAndTarget.*</value>

        </property>

    </bean>

Spring pointcut as a real pointcut thanks to the wedding with AspectWerkzPointcutAdvisor

    <bean id="theMethodExecutionAfterThrowingAdvisor"

        class="awbench.spring.AspectWerkzPointcutAdvisor">

        <property name="advice">

            <ref local="theMethodExecutionAfterThrowingAdvice"/>

        </property>

        <property name="expression">

            <value>execution(* *..*.afterThrowingRTE(..))</value>

        </property>

    </bean>

Such a basic code source is there and should perhaps be reviewed by Spring guys for some of the API details.

The great news is that this will be part of a next release of Spring, and details will be handled by the AspectJ 5 engine instead. That was about time ;-)

Today we have finally announced that we are joining AspectJ to work on AspectJ 5.

We will focus on what has been the success of AspectWerkz
- plain Java AOP, relying on an annotation defined aspect style
- load time weaving, and integration in J2EE environment

The new team is backed by both IBM and BEA and the new project will be delivered in the coming months. One of the priority is to make sure that a smooth migration path exists from AspectWerkz to AspectJ 5.

That' s a great day for AspectWerkz and AspectWerkz users.
Read more about it

I am pleased to announce the first release of YAPB AOP.

For those who don't like this April Fool like YAPB AOP, please read this post on The Server Side - read
Note: YAPBAOP is a real project with real source code and runnable demo !

Features
YAPB AOP 1.2.3.4 is Yet Another Proxy Based AOP for Java.
It is
- proxy-based (AspectWerkz proxy)
- pure java, no language extensions, no external tools needed
- simple and intuitive
- direct, programmatic configuration and un-configuration
- j2ee friendly, no need to mess with class loading
- supports AOP Alliance API for MethodInterception
- JDK 1.5.0 annotations support to match on annotation
- per instance programmatic interception
- full speed

Sample code
here is how YAPB AOP 1.2.3.4 use is simple:

// no aspect

System.out.println(" ( no aspect )");

YapbaopDemo me0 = new YapbaopDemo();

me0.method();


System.out.println(" ( bind a new aspect )");

Yapbaop.Handle handle = Yapbaop.bindAspect(DemoAspect.class, "* yapbaop.demo.YapbaopDemo.*(..)");

YapbaopDemo me1 = (YapbaopDemo) Proxy.newInstance(YapbaopDemo.class);

me1.method();

handle.unbind();

// get a new one but not using the proxy cache then..

System.out.println(" ( unbind it and get a new proxy YapbaopDemo-2)");

YapbaopDemo me2 = (YapbaopDemo) Proxy.newInstance(YapbaopDemo.class, false, false/*not advisable*/);

me1.method();// still has advice

me2.method();// no advice

Extra features
It was very boring to do and does not bring any value to the table, so please, stop inventing (is is the right word ?) YAPB AOP clones based on your favorite bytecode library / proxy library.

It took 40min to hack (time for a train trip, YAPB AOP are that easy today).

If you want to do something usefull, write an email to your favorite AOP framework representative (AspectJ, AspectWerkz, JBoss AOP, Spring AOP, dynAOP, joyAOP [RIP ?], jeetAOP [RIP ?], YAPB AOP [RIP]) and wonder how to
- write some usefull reusable aspect
- write some good article
- provide a new feature, a performance improvement, a bug report or fix
- go an apply to speak about it to the next conference you can find
- imagine new things !

Download Now !
- Get it there (3 Mo jar since YAPBAOP is actually 1 class of 200 lines messed with a lot of dependancies so that you think it is a killing framework)
- Run the demo with:

java -cp yapbaop-1.2.3.4.jar yapbaop.demo.YapbaopDemo

Access the source code
The framework - here
The demo to play with - here
The AOP alliance aspect for the demo - here

Write your own !
Ever wanted to be an Open Source star [*] ? Write your own. Enroll now !
[*] A wrong assumption seems to be that to be an Open Source star, ones have to write at least one YABP AOP. If you only contribute to the next big thing, you ll never be a star, so you 'd better start your own YA RIP framework instead of working with others - that's what mankind is about according to this wrong assumption.

Here are some ideas :
- change the Yapbaop.bindAspect to support binding to a java.lang.reflect.Method
- do the same with an array of java.lang.reflect.Method
- do the same with 1+ Method Annotation(s)
- add some filtering based on 1+ Class Annotation(s)

If you have read till there
Thanks to read this post.
If you dig YAPB AOP architecture, you will find that it is based on
- AspectWerkz proxy
- AspectWerkz extensible AOP container to support AOP Alliance aspect
- AspectWerkz runtime as regards binding of aspects
Quite interesting actuallly isn'it ?

Well, we for long have said that plain Java AOP and annotation defined aspects don't needs fancy GUI support, but I have to admit, this makes everyones life easier.

So I am pleased to announce the availability of the AspectWerkz Eclipse Plugin based on the 2.x releases.

Get it now, see the doc and the screenshots !

The plugin contains two almost disjunct features:

• an embedded compiler (a builder in the Eclipse plugin world) for our Java 1.4 strongly typed annotations. Just write the annotations as you would do with Java 5 but in JavaDoc (arrays, nested annotations etc are supported), and write one interface per annotation (where you would write an @interface with Java 5), and the plugin will do the trick when Eclipse will compile your code.
  The annotations are then accessible at runtime (using AspectWerkz Annotations API)and you can use them in your pointcuts (nothing new there).
  


• a glue layer that shows the cross cutting view that is add little markers in the gutter to remind you that this piece of code at that line (join point) is advised by this and that before advice in this and that aspect.
  

(Each feature is a builder so you can deactivate them on a a per project basis if you don't like them / use them.)

Aside since your app will gets weaved, you can just click run and the aspects are in - nothing more to do.
If you need to expose your dependencies jar files to the weaver, use the dedicated AspectWerkz launch configuration that will configure load time weaving for you.

Feedback welcome.
Any volunteer for further evolution ?

The plugin ships for Eclipse 3 and Java 1.4. More to come on Java 5 later.

Alex

Oh forgot to say before others make a story about that: yes we are the last one to write an Eclipse plugin, way (decades?) after AspectJ and some month after JBoss.

I am back from the JAOO conference that is happening this week in Aarhus, a city in the west part of the Denmark.
Jonas and I had the opportunity to speak there, and since I feel that there is only a little coverage of it in the blog
community, I have decided to take care of that DK duty.

This post won't give you the right view on this conference, since I attented to my own fields related session aka AOP related, but anyway, you will have a minimum.

The conference

The conference is this year largely sponsored by Microsoft, among others of the .Net or Java ground. Great guys are speaking there, like Rod Johnson (Spring / Interface21 - you know him), Rickard Oberg (former JBoss ejb guy, closed source AOP/CMS lead at Senselogic) , Martin Fowler, Arno Schmidmeier (early AspectJ user, AOSD consultant), Peter Von der Ahé (javac Sun guy), Jonas Bonér and myself to name a few and a bunch of .Net guys.

Though the conference location was a bit far from the airport, the accomodation was good, lunches were fine, with DK stuff but not too much for a FR guy, and the monday night social party was pretty good.

Day 1 - Keynote by Microsoft

I have attended the monday keynote given by a Microsoft guy. It was a good insight to see what MS is attempting to achieve, thinking ahead the C# things while people are just excited about the upcoming release of a new Visual C# things.

it was interesting to hear about how clever is Microsoft when it leads to the latest Java 5 Tiger new features, which are some sort of compiler trick for most of them.
In .Net, when you have an int, this one is an object, and there is boxing / unboxing features somehow, but the int himself is reflectively accessible. In the Java world we have blessed (or cursed as Jonas said...) primitive types (int ...) and boxed types (Integer etc), and Tiger provides boxing and unboxing but thru a compiler trick - that is the bytecode will make use of yourInteger.intValue() and Integer.valueOf(yourint) under the hood.

Microsoft gave a bunch of other samples, and admitted that it was somehow easier to start a good language desgin from scratch that sketching on an existing one.

Day 1 - Sessions

I did not attended more on monday morning since I had to prepare some for our own session and I hope to see someone providing feedback on it since it is not fair to write it myself but still...

Annotation driven AOP with AspectWerkz

Jonas and I were giving a talk in the J2SE track on Annotation and AOP.
We started with an AOP crash course just to get everyone on the train.
Then we explained how Tiger annotations are used in AspectWerkz to have annotation defined aspects (something that JBoss has recently lazily followed).

Annotations are also used in AspectWerkz as a matching mechanism, and we went thru a sample where it is perfectely safe to refactor your methods without taking care about the underlying AOP without any whatever IDE plugings.

You can check our slides there, but for the impatient, here is how our strongly typed matching aspect looks like for annotation driven AOP. As you can see, there is no string based, wildcard based magic there.

// Annotation driven AOP
// Sample of strongly typed matching
// in AspectWerkz AOP with annotations

@Service

public class Math {

  @Async

  public Result complexComputation(Arguments args) {

    ...// this may take a while - we should do it in another thread

  }

}  

public class AsyncAspect {

  @Around

  @Within(Service.class)

  @Execution(Async.class)

  Object doAsynchronously(JoinPoint joinpoint) {

      ...

  }

}

The session went fine, and the room was pretty much full, with around 400 attendees and after the session we met and chatted some with Rickard Oberg.

After that we had a sort of J2SE panel, which turned out to be a BOF since the JAOO crew had not provided us with a moderator. It ended up in discussing some details and pitfalls in the new Tiger features, like generics and static import.

Night 1 - All conferences are about social events

In the afternoon we met Arno Schmidmeier, an early AspectJ user (meaning late 90's), who is now doing AOSD consulting in Germany (give him a call if you need some AspectJ on-site knowledge), and we then head up to the social event / party with Rod Johnson. Time to share a bunch of beers paid by JAOO sponsors (Microsoft, Borland, Quest, and then I don't really remember) while discussing ideas about Proxy based AOP as in Spring, Geronimo integration, Spring AOP container for AspectWerkz, and some other things.

Day 2 - Sessions

On day 2 I had to leave early and get back at work so I could only make it for Arno and Rickard'sessions and missed Rod' session unfortunately.

AOP - let the code looks like the design

Arno Schmidmeier gave a talk in the Domain Driven Development track, where the main point was to explain how AOP could allow you to let the code looks like the design.

He went thru some use-cases he had seen during his consultancy jobs, and the most interesting part of the session was when he explained how an expression for a domain requirements like "for every successfull bank account operation the accont balance must be checked after the operation and in case of failure, an error should be triggered by the system and the system notified that it should rollabck etc." could be mapped to an AspectJ after returning aspect and thus making his points that AOP enables you to have the code look like the design while avoiding code tangling issues.

Attendees raised questions about code readability, modelling issues and similarities to a predicate language approach. I would have liked to see a running samples in AJDT and alike, and be able to navigate thru the aspects, and may be emphasis more on the domain level pointcuts idea.

Rickard experiences on AOP

I attended Rickard talk about experiences on AOP.
Rickard ellaborated a talk around many of the complex use-case he has for AOP in his company (Senselogic) CMS platform. He started with some classis technical domain concerns, and then jumped on his idea of interface driven system, where an object is actually decomposed in an assembly of entities, each one having a defined stack of advices attached to it.

This approach, which seems quite close to quantum AOP concepts, opens for a bunch of interesting things when it comes to GUI update propagation and server to server replication of sub-graph of persistable objects as well as undo/redo management which again should propagate...

Rickard introduced the idea of a "property=development|production|whatever" pointcut element, that allows for sort of global on/off on the pointcuts. Something you can achieve with a "if" pointcut in AspectJ - although he probably did implemented it at weave time and not at runtime unlike the AspectJ "if".

Rickard then explored the advantages and drawbacks of his "home made" AOP framework, and explained the idea of the abstract schema, where the aspect is abstract and then implements interface of classes where it is actually weaved to, providing sort of natural syntax for accessing the advice target instance methods from within the advice body.

He then went thru a small demo wich showed a nice swinguish things, and then went thru some ajdoc equivalent, where generated javadoc for a class/member is exposing which advices are bounded to it and thru which pointcut.

The next session was Rod Johnson session on Spring and Spring AOP. Unfortunately Jonas and I had to leave since mh, we are pretty busy these days.

Wrap up

Those 2 days were a good investement. I enjoyed the talk we gave there, and it was nice to meet and discuss more with people like Rod, Arno and Rickard.
JAOO has probably a lot more to offer, even if you are on the .net side or on both side (ThoughtWorks had a booth there by the way).
I had some time to think about Rickard abstract schema and experiment some more on Tiger annotations - something I will try to blog about soon.

Get to see the schedule and the JAOO slides there.

Below are some picts of Jonas, Arno, Rickard.

Jonas speaking

Arno session

Rickard explaining his Abstract Schema

Jonas and I are going to speak at JAOO about Annotation driven AOP in Java (Tiger / J2SE 5).
The session will cover aspects defined as annotated java classes, as well as matching on annotations and defining strongly typed pointcut thru annotations.

This is a great opportunity to speak there, especially since those ideas have been implemented since the early time of AspectWerkz. Something that some of the other AOP framework are now following.

I have sketeched a BEA WebLogic domain wizard, so that it is now possible to install a WebLogic server with AspectWerkz AOP in a minute.

Requirements:
- WebLogic 8.1 SP2 (8.1 whatever should work).
- Use of JRockit is mandatory for now (included in WebLogic 8.1 or other version if you want).

How to:
- Download the jar (7 Mo, includes the whole AspectWerkz 1.0beta1 distribution with some extra fix).
- Drop the jar file in your BEA_HOME/weblogic81/common/templates/domains.
- Start the BEA Configuration Wizard from the start menu.
- Select the AspectWerkz node and the "WebLogic WorkShop domain".
- Select JRockit
(for other screens, refer to the usual BEA installation documentation)

Limitations:
- It is a WebLogic WorkShop domain wizard. You can probably adapt it for WebLogic Server only, or WebLogic Integration and WebLogic Portal
- Use of JRockit is mandatory, although it is possible with some minimal change to adapt the generated "startWebLogic" script for Sun HotSpot VM (I would do it with the AspectWerkz Plug utility and -Xbootclasspath option - refer to the documentation).
- If you are not using 8.1 SP2, you might need to adapt the "startWebLogic" script to set your JAVA_HOME to the correct JRockit version.

Extra bonus:
- There is draft version of a WebLogic AOP console extension included, that allows you to browse the META-INF/aop.xml definitions accross the class loader hierarchy of your deployed applications.
Just start the weblogic admin console as usual and the extension will appear on the left navigation pane.

Since we released AspectWerkz 1.0 beta 1 some days ago, with a real cool feature we had in our roadmap since the very begining, I have written a small tutorial for you to practice.

AspectWerkz now supports the concept of an AOP container. No other AOP framework out there supports this idea in the way we do it : class loader aware and cross platform.
It is now possible to have an AOP deployment descriptor within your application, and interesting point in an AOP world: have several of them, all along your application.

The standard way of doing so is to use META-INF/aop.xml files, and for some container like Tomcat it is possible to use WEB-INF/aop.xml as well.
If you add a jar file in your application and this jar file contains a META-INF/aop.xml descriptor, it will also be taken into account. It is thus easy to distribute aspect jar file with predefined behavior.

You can drop Aspect classes at your system classpath and those will affect all deployed application, AND, you can have Aspect classes within your web application that will only affect this specific deployed application.

Read the tutorial here.

Note that if an Aspect is deployed within an application, the pointcut it defines will be limited by the class loader isolation principle. Even if the pointcut assumes to match all method in all classes, it will only "see" all methods in classes loaded by this classlaoder and the child classloader.

Try it now !

On several recent ML post AspectWerkz users complained about getting into troubles when hooking in AOP in Tomcat 5. Steve provided good feedback but ... there is off course a damned better way to handle that !

Here is a little hands on that gives the idea for a 5 minutes shot.
Pretty much straigthforward based on

• cvs head ie the next 1.0 beta and not 0.10


• no integration detail, just some bin/aspectwerkz.bat magic


• aop.xml deployed wihin the target application itself


• a little fix in a strange Manifest.mf file in qdox-1-3.jar

I was concerned about this issue and had an hectic face to face burger discussion with Jonas about "my" so called seamless integration of AOP... I needed to sit down on that and hack, too bad for the jet lag in this crazy GMT 9h far from home SF BEA eWorld clock.

Since the Codehaus had to migrate some CVS details today, the little qdox.jar fix that is needed cannot be commited, but just do it yourself if you want to go on with those explanations. Or wait tomorrow since Bob the despot is around there as well... He'll fix that for me if he is not too busy on the new Codehaus / BEA BeeHive stuff there.

So I took a Tomcat 5 from Apache, unzipped the stuff on my windows box.
I checked that it was fine with the bin/startup.bat and shutted it down to spread AOP in.

Then I made sure that AW *cvs head* was builded, and ASPECTWERKZ_HOME and JAVA_HOME was set.

I decided to give a try to this integration issue and decided to start with a silly tracing aspect that is sitting in AW samples (examples.logging.JavaLoggingAspect). I then builded the samples with a maven target (aspectwerkz:samples:compile)and had a new target/aspectwerkz-samples.jar ready to use.

Then I just opened this bin/catalina.bat that is actually starting things and added this just before the comment:

        rem Execute Java with the applicable properties

        ... 

        set CLASSPATH=%CLASSPATH%;%ASPECTWERKZ_HOME%\target\aspectwerkz-samples.jar

        set _EXECJAVA=%ASPECTWERKZ_HOME%\bin\aspectwerkz.bat

        set JAVA_OPTS=%JAVA_OPTS% -Daspectwerkz.transform.verbose=false

You will have noticed that I just added my silly tracing sample aspect in the CLASSPATH and replaced bin/java call by bin/aspectwerkz.bat - not taking care about the details.

From there, Tomcat started up *almost* fine. The AW/lib/qdox-1.3.jar has a strange Manifest.mf file that Tomcat complains about... Just dropped this Manifest.mf from the qdox.jar and we are up and running with AOP online mode / class load time weaving / AOP container from cvs head.

Time to bind my system level tracing Aspect to some application.
I did a try by writting a 5 lines aop.xml file (actually copy pasted it from AW samples/hotdeployed.xml) and dropping it in Tomcat samples in webapps\servlets-examples\META-INF\aop.xml, since this is what we now provided in cvs head (and not in 0.10).

Once that done, nothing happened. I added some tracing stuff (-Daspectwerkz.transform.verbose=true) and figured out (with a bit of pain since toString() on Tomcat classloader is damned too much verbose..) that Tomcat classloader is not taking this META-INF topmost stuff into account.

and here it is (once I browsed to http://localhost:8080/servlets-examples/)

METHOD_EXECUTION--> filters.ExampleFilter::doFilter

  METHOD_EXECUTION--> HelloWorldExample::doGet

  METHOD_EXECUTION<-- HelloWorldExample::doGet

  METHOD_EXECUTION--> filters.ExampleFilter::toString

  METHOD_EXECUTION<-- filters.ExampleFilter::toString

METHOD_EXECUTION<-- filters.ExampleFilter::doFilter

METHOD_EXECUTION--> filters.ExampleFilter::doFilter

  METHOD_EXECUTION--> SessionExample::doGet

    METHOD_EXECUTION--> listeners.SessionListener::sessionCreated

      METHOD_EXECUTION--> listeners.SessionListener::log

      METHOD_EXECUTION<-- listeners.SessionListener::log

    METHOD_EXECUTION<-- listeners.SessionListener::sessionCreated

  METHOD_EXECUTION<-- SessionExample::doGet

  METHOD_EXECUTION--> filters.ExampleFilter::toString

  METHOD_EXECUTION<-- filters.ExampleFilter::toString

METHOD_EXECUTION<-- filters.ExampleFilter::doFilter

aop.xml

<!DOCTYPE aspectwerkz PUBLIC

    "-//AspectWerkz//DTD//EN"

    "http://aspectwerkz.codehaus.org/dtd/aspectwerkz.dtd">

<aspectwerkz>

    <system id="sample">

        <aspect class="examples.logging.JavaLoggingAspect">

            <pointcut name="pc" expression="execution(* *..*.*(..))"/>

            <advice name="logMethod" type="around" bind-to="pc"/>

        </aspect>

    </system>

</aspectwerkz>

]]>

Conclusion
We are almost there and 1.0 will be damned good don't you think ?

In a recent post Bill Burke describes his preliminary research as regards HotSwap usage for dynamic AOP.

He first defines in a few words what is dynamic AOP and what is the HotSwap or class redefinition in Java. Then he briefly describes how JBossAOP handles dynamic AOP thru a "prepare" phase, and gives some measurements about the overhead he obtained when using the -Xdebug mode during a JBoss startup sequence, an option required to activate the HotSwap API under Java 1.4.

I would like to give some feedback on his post, since I have been working in the dynamic AOP field for some time now thru my involvment in AspectWerkz and thru a research paper and a runtime weaving prototype I did for the Dynamic Aspect Workshop for AOSD 2004.

I think dynamic AOP has to be splitted in two categories:

• rearranging AOP constructs at existing join points
• redefining join points (we could generalize with redefining pointcuts, or even redefining the whole AOP system)

The first category is fully supported by AspectWerkz. It is possible to rearrange (add/remove/reorder) aspects and advices at runtime providing that the join point(s) where the construct(s) is(are) bounded is(are) already existing as a result of the transformation phase, no matter it is a post compilation phase (ala AspectJ) or a class load time weaving.

As regards introductions, AspectWerkz allows to change the introduction implementation (thus the implementation of the added methods) at runtime (swap mixin implementation), again providing that the binding (which mixin(s) applies to which class(es)) is already existing.

This first category relies on the framework capabilities and several means allow to minimize the overhead when f.e. no advice is bounded at a particular join point.
The overhead even if minimal cannot be avoided here. Even reduced to a method call that does a boolean check, this is not the original bytecode instruction sequence which is running when the join point is reached.
This category is the one supported by JBoss as well.

The second category is the most interesting one. Redefining join points (thus pointcuts) allows - in theory - to add new AOP construct at new locations (join points) in the running application. This should come with the guarantee that there is

• absolutely no runtime overhead prior the "activation" of the new join points, and no overhead after "deactivation"
• no assumption that the join points are known before activation (especially at class load time / application deployment time)

I think that this second category requires runtime weaving capabilities from the AOP framework (as long as the AOP frameworks rely on bytecode instrumentation).

A use-case for join point redefinition at runtime is some on-demand profiling tool that needs to activate profiling only when necessary, for a limited time, and without any overhead prior to activation, and without specific knowledge on what will be profiled at application deployment time.

As Bill explains, JBossAOP "addresses" the second category by providing a way to declare pointcuts with nothing bounded. This definition is used at class post compilation / class load time and is what Bill calls the "prepare phase".
The overhead involved by such an approach is not measured by Bill, but is conceptually limited to a boolean check and a method level indirection, this for each pointcuts declared for future activation.
I don't think this approach is really adressing dynamic AOP. The overhead at a single join point level is indeed minimal, but we might have a need to declare very invasive pointcuts to allow further on-demand profiling (or other AOP based constructs), and thus this minimal overhead might occurs trillions times in the running application (potentially at each method call, each method execution and each field access).

So what might be a better solution for true runtime join point redefinition ?

As Bill quotes, HotSwap API allows to change the implementation of method / constructor bodies of a class at runtime, and inject them in the running JVM.
There are some interesting things to consider, that Bill forgot to mention and led him to some approximative statements (I forgot to told him ;-) )

• HotSwap is an optional JVM capability. Some JVMs do not have HotSwap support (f.e IBM JRE)
• HotSwap might forbid class schema change. It might not be possible to add new methods (even private ones) to a class when redefining it. This schema change support is itself an optional HotSwap capabilitiy. Currently no JVM supports schema change, but the API does not restricts it.
• HotSwap exists since Java 1.4, requires -Xdebug mode, and can only be called from a remote JVM (well almost, read below)
• HotSwap is slightly modified in Java 1.5 and does not requires -Xdebug mode

So considering what HotSwap can do, and what bytecode instrumentation oriented AOP frameworks do to enable AOP in Java OOP, especially to enable dynamic AOP constructs of the first category I described previously, HotSwap seems very attractive, but is currently missing key things.
There might be some ways to address the problems thought...

The fact that the java level HotSwap API as described in Java 1.4 JPDA requires a remote JVM attached to the running JVM (or a JPDA LaunchingConnector) can be avoided by implementing a JNI layer on top of the C-level HotSwap API so that HotSwap is available at Java level, without coupling with the JPDA architecture: no need for a remote JVM, and no need for a LaunchingConnector (that would forbid further remote dedbugging ...).
I describe the advantage of this JNI glue in the work I submitted to the DAW AOSD 2004, and call it "in-process HotSwap". We have it in Java 1.5 so there is no problem on this side anymore.

The "in-process HotSwap" - Java level API - is standardized in Java 1.5 thru the JSR-163. Java 1.5 will not requires -Xdebug to enable the HotSwap API. As you might have understood, the HotSwap API is not that coupled to the JVM debugging capabilities, althought the API was part of the same block in Java 1.4.
The -Xdebug overhead issue raised by Bill is fixed (though I would like to do measurement of what -Xjavaagent in Java 1.5 involves).

The schema change support would be interesting for AOP join point redefinition, since as Bill explains, AOP frameworks that allow dynamic AOP (AspectWerkz, JBossAOP) require some structural changes to bring in enough indirection level between the join point (in the weaved classed) and the AOP constructs (handled by the AOP framework internals).

A simple bytecode decompilation of an AspectWerkz weaved class with execution pointcut will show you that AspectWerkz has added a wrapper method to handle the join point and renamed the original method, since it will be called by the framework as a result of the execution join point construct.

class Foo {
   
   public void doAction() {
      // the bytecode for your code
    }
   
}

can appeared transformed after the weaving as (approximation)

class Foo {
   
   JoinPointManager __AW_joinPointManager =...
   
   public void doAction() {
      __AW_joinPointManager.proceed(this, "doAction()"); 
    }
   
   private void __AW_doAction() {
      // the bytecode for your code
    }
}

As a consequence, if we would like to be able to redefine (f.e. simply define) the "* Foo.doAction(..)" execution pointcut at runtime, we would need schema change support. The schema change support might not be needed though for caller side constructs.
The problem is thus more a HotSwap API problem, tight to current JVM limited capabilities.

I think that HotSwap - if largely adopted by JVM implementation - can be a good enabler for dynamic AOP as regards pointcut redefinition at runtime. I don't think that the debate is limited to a -Xdebug option, and Java 1.5 demonstrates it.
In the work I submitted to the DAW AOSD 2004, I describe how we are able in an AspectWerkz prototype to redefine pointcuts at runtime even without schema change support.

I agree that this solution (which I will publish later in my blog) is itself not optimal but I was able to demonstrates the feasability of such an on-demand AOP approach, instead of an invasive pointcut definition, that might itself lead to a globally large overhead. I was able to do the prototype with Java 1.4, and it will be even more easy to do with Java 1.5 and the standardized "in-process" Java level HotSwap.
I will debate if HotSwap is good for dynamic AOP at the DAW AOSD workshop, and you bet, some more JVM level AOP support might be crucial on this area.

So far so good, what do we wanted ?

Probably not a low level "addPointcut(<pointcut pattern>, Class klass)" API with a controlled and guaranteed minimal (or even zero) global overhead prior activation, but maybe a more usefull system wide control like "addAOPSystem(ClassLoader klassScope, SystemDefinition definition)" to be able to activate AOP constructs as a whole, at runtime, and leaving the internal recipe of it to AOP solutions and JVM implementations ...

Right ?

Today I finished my implementation of the new AspectWerkz pointcut expression language.

AspectWerkz had already a good usability level as regards pointcut expression. Most of the needed syntax to bind pointcuts with advice or introduction had been implemented by Jonas, based on an algebra backed by Jexl.


/** @Aspect perJVM */
public class MyAspect extends Aspect {

}


The previous implementation supported the complete AND / OR / NOT algebra:

pc1 OR pc2
pc1 AND ( pc2 OR pc3 )
pc1 AND NOT pc2
...

And some synonyms were also provided, like &&, || and !, and other lowercased operators (or, and, not).

What I found bad with this Jexl based implementation was the following:

• very hard to add new syntax operator (like IN for cflow pointcut composition)


• added a programmed AST on top of the Jexl AST, but without providing a true Visitor pattern exposure


• lost boolean expression optimization f.e. needed to evaluate all pointcut in an OR expression like pc1 OR pc2 even if pc1 matched


• used only a tiny part of Jexl capabilities (Jexl is the evaluation engine of Velocity)

After some digging in Jexl extensibility I decided to start my own boolean expression implementation based on a JJTree grammar. In two days I had the complete operator set I needed, and a true Visitor pattern exposure.

In other two days I was able to refactor Jonas' work to plug my JJTree implementation in AspectWerkz. It allowed to solve a pending issue we had in the 0.9.RC1 release as regards cflow support for model 2 JSR-175 style Aspects.

Now we have many advantages at the hand:

• no impact for the user


• faster, especially when boolean optimizations are possible


• cleaner, with Visitor pattern


• more usable: with the new cflow composition thru the IN operator

From a user point of view this grammar add a new operator for cflow: the IN and NOT IN (or ! IN etc ...).
It allows to express in a natural way the pointcut expression with cflow.
pc1 OR pc2 IN cflow1
is then different from
( pc1 OR pc2 ) IN cflow1
[ the previous syntax was not natural : pc1 && cflow1 ]

In the next month, I should have time to add the needed glue to support several level of cflow composition - since this is already supported by our JJTree grammar :
pc1 IN ( cflow1 OR ! cflow2 )

This time, the trick will be more at the runtime during the joinpoint evaluation.

Today while having my daily googling time on AOP, I found a 25 pages article about JMangler, a class load time weaving solution I had already bloged about.

The paper is here as a PDF.

I am rather surprised when I read that and mirror it with the fact that AOP would gain from massive adoption. I will defend my position in a very near future, but i could not avoid this flameware snip.

JMangler quotes itself as A Powerful Back-End for Aspect-Oriented Programming. And you might even buy a Prentice Hall book in 2004 to learn that.
I will save your time and money, by explaining you (again) why AOP does not gain from such a low concrete achievement strategy.

Just to let you think about by your own while I am writting my flameware:

• Will you buy a book in 2004 to learn that JMangler is used in AspectWerkz ? This is false: JMangler had been in AspectWerkz but has been kicked out since july 2003 and we are happy.


• Have your read that AspectWerkz hooking provides native support for BEA JRockit ?


• Have you already worked with IBM JRE class loading scheme


• Should a powerfull solution - that claim to be compliant with J2EE - fail under WebSphere environments ?
  
• Should a powerfull solution be SUN JRE 1.4 centric ?


• Should it hang when used in J2EE architectures ?


• Should it run only in -Xdebug mode, with two JVM side by side ?

Is that a joke ? Abusing the AOP hype in the Academic sphere ?
Software is a moving thing, and AspectWerkz makes AOP move fast. Be ready.

Samuel has done a viewlet where he demonstrates how to easily debug an application and its aspects with AspectWerkz from within Eclipse.

If you did not yet understood how standard and easy it was from my first annoucement, you have to watch it now !

All is explained step by step. This is a definitely a things to work with.