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

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.

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. ]]> AOP avasseur 2005-10-20T11:22:02+01:00 http://blogs.codehaus.org/people/avasseur/archives/001191_synchronized_block_join_points_v2.html synchronized block join point. The discussion was interesting but I am wondering if we actually came up with the right question.

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) { .. } } } So the deal is to listen to lock events - mainly:

• 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) { .. } to if (stuff instanceof Lockable) { Lockable lockable = (Lockable)stuff; lockable.waiting(); synchronized(stuff) { lockable.acquired(); ..// unchanged body } lockable.released(); } else { synchronized(stuff) { ..// unchanged body } } Fairly easy.

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: http://blogs.codehaus.org/people/avasseur/archives/001152_aop_weavers_are_we_doing_it_wrong.html 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?]]> AOP avasseur 2005-08-10T12:18:40+01:00 http://blogs.codehaus.org/people/avasseur/archives/001141_jvm_support_for_aop_in_bea_jrockit.html 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.

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.]]> AOP avasseur 2005-06-23T11:31:48+01:00 http://blogs.codehaus.org/people/avasseur/archives/001107_jrockit_aop_and_aspectj_5_and_javaone_2005.html 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 !

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 ;-)

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

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 ?

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.