Microsoft goes AOP?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

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.

Spring 2.x - innovation or maturity?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Last week I had the pleasure to discuss some more with the Spring team at JavaPolis, and I was thus given a quick informal update on what they are heading at in Spring 2.x, especially on the AOP side, discussing with Rod and Rob.

Spring AOP in Spring 1.x has been easy to use - though missing a good pointcut language. This simplicity is well described in a recent article on dev2dev by Eugene, and I had debated this issue and tried to solve it with Spring pointcuts on steroids with AspectWerkz.

In Spring 2.x, with the help of newly appointed excellent Adrian Coyler as chief scientist, my AspectJ lead peer, Spring AOP will unleash AspectJ and @AspectJ that I spent quite some time on this year as per our engagement to merge best of breed AspectWerkz with AspectJ.

But going beyond, Spring 2.x also introduces a way to define aspects in your spring bean xml files directly f.e.:









This is actually a really nice feature that I started playing with 2 years ago when implementing AspectWerkz with Jonas. So there is not much innovation there.

There might actually be some issues and hard work going forward. By having aspects defined this way, the AspectJ runtime that is used when your are using the excellent AJDT Eclipse Plugin for AspectJ will not take those into account (whilst regular @AspectJ ones are fully supported).

This means there 'll be definitely a need to open-up some more AJDT and have some extension point in it so that the Spring IDE can leverage it and have the AJDT crosscutting view display the Spring xml defined aspect.

Wups - xml defined aspect I have said - just like this June 2003' Jonas article introduces, back in AspectWerkz 0.6.3

Maturity - finally!

JRockit powered AOP prototype available

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

It's there !

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.

Synchronized block join points (v2)

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Back in July Jonas suggested some semantics for a 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:

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!

How will nextgen AOP looks like?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

This last days I have been thinking some about how next gen AOP implementations may look like in say 4 years from now in the Java landscape.

As you may known, 5 years ago AspectJ was not based on bytecode manipulation but was based on source code transformation.
As of today, full blown AOP like AspectJ and JBoss AOP are usually build on top of really heavy bytecode manipulation, while more lightweight approach like Spring AOP are build on top of proxy (which under the hood can use bytecode generation technology ie JDK or CGlib proxy).

In the next few days we will start spreading the prototype implementation of AOP support in JRockit JVM which allows to implement all of the AOP interceptions features without even touching the bytecode but with a more abstracted subscription based API. If you missed the dev2dev series you can read more about it there.

This technology is definitely a breakthrough in the field, but does not address the introduction/mixin features ie capability to add method / field / annotation / change the object hierarchy of the object model in a crosscutting manner.
This means that f.e. to implement AspectJ as it is on top of the new JVM based technology we need to wether

• remove the feature from AspectJ - this is dumb as introduction are an important part of AOP


• do that in the VM - well, perhaps but unlikely from my perspective as it would mean changing the Java language itself else ones would not be able to call the introduced members from regular code


• use an hybrid bytecode / VM based AOP approach - why not but it looks a lot like going back to the old bytecode based implementation complexity


• do it in another way!

My thoughts on that is that we will likely do it in another way - and perhaps going back to source code transformation. This year Sun' folks presented the Jackpot project at JavaOne - which is sort of a rule driven source transformation engine. If that ones goes mainstream somewhere with Java 7, ones will have a fairly great technology set to rethink the way we implement AOP in Java, mixing nextgen APT (that will expose the full AST), Jackpot and JVM weaving.

AOP weavers - are we doing it wrong?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

These last days I have been prototyping around an interesting idea.

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?

JVM support for AOP in BEA JRockit

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

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.

AspectJ 5 load time weaving with Java 1.3 using ... AspectWerkz

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)


**** 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

I have integrated the most important ones in the AspectJ 5 code base already - ie the first two - but some of them won't be integrated - hence this post.

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:










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




.....






**** 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.

Opt-out AOP: good or evil ?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

There is an interesting option in AspectJ that is named -Xreweavable.

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 ?

@AspectJ in AJDT - a world premiere !

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

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)

AspectJ, @Aspect and Java 1.3

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Following the Backport175 release that Jonas and I have done some days ago, and since AspectJ 1.5 upcoming M3 and especially the @Aspect style is starting to take shape after some month of hard work on my side, I think it is a good timing to also explain that this @Aspect sytle, despite its name tied to these Java 5 annotations, is not at all tied to Java 5, and will bring the plain Java aspect concept to all of you using Java 1.3 and 1.4 (from the real world).

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 - AOP, distributed Java, and more

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

I thought it would be interesting to post what kind of session and BOF I am planning to attend during JavaOne 2005 next week.

There are indeed interesting trends going on, and needless to say I don't really want to hear that the EJB (3) XML deployment descriptors are back or that kind of things. Instead, AOP, Annotations and distributed architectures will get my interest.

• 
  BOF-9888, Chasing 9s: Modeling and Measuring Availability of J2EE™ Applications (Sun, monday 7h30 PM)
  


• 
  TS-7659, Runtime Aspects With JVM™ Support (BEA JRockit off course, Tuesday 11h AM - don't miss it ! and meet us at the BEA and Eclipse booth)
  


• 
  TS-7695, The Spring Framework: Introduction to Lightweight J2EE™ Architecture (Interface21, Tuesday 11h AM)
  


• 
  TS-7212, Clustering, Consistency, and Caching: An Implementor's View of JSR 107 [JCache] (BEA, Tuesday 01h30 PM)
  


• 
  TS-7159, Java™ Platform Clustering: Present and Future (Sun, Tuesday 2h45 PM) (don't miss it, it is a sneak from Sun research labs, about transparent clustering)
  


• 
  BOF-9385, Apt Usage of APT: When and How to Use the Annotation Processing Tool (Chariot Solutions, Tuesday 7h30 PM) (I know they will give a quote to AspectJ)
  


• 
  BOF-9161, Exploring Annotation-Based Programming Through the APT and Mirror APIs (BEA/Sun, Tuesday 9h30 PM) (ha ! Annotations that drove AspectWerkz for a while)
  


• 
  BOF-9441, Practical Application of Aspects in Everyday Development (ALTERthought, Tuesday 10h30 PM) (AOP from the users - an evidence of adoption phases as regards AOP)
  


• 
  TS-5471, Jini™ and JavaSpaces™ Technologies on Wall Street (JPMorgan, GigaSpaces,others, Wednesday 11h AM)
  


• 
  TS-7429, Speculative Locking: Breaking the Scale Barrier (Azul, Wednesday 4h PM)
  


• 
  TS-7410, Network Attached Processing: Tapping 384-Way SMP, 256GB Java™ Technology Compute Bricks (Azul, Thursday 1h15 PM)
  


• 
  TS-7339, Data Grids for J2EE™ Platform Cluster Deployments (GemStone, Thursday 3h45 PM)
  

See you there !

JRockit AOP and AspectJ 5 and JavaOne 2005

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

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 !

Java Open Source playing with sharks

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

As a person largely involved in the Java Open Source landscape, I have been observing radical changes during the last 5 years in this area, and the 5 years birthday of Struts makes me comment it some.

Five years ago, I was starting my own Struts clone for PHP to try to bring an MVC model to the rather new PHP OO stack I was using on a customer site. This project ended up pretty much nowhere (e-php on SF) since, well..., I could luckily do something way more interesting.
But back at that time it was rather simple to start a small Open Source project and try to have it grow. Some were actually even considering you as a strange beast when you happened to be part of that world, one of my former employer beeing the first.

At that time, I also remember sales folks arguing that a Java developer had to have "fluent in Struts" in their resume to actually be a good Java Joe developer (before that you had to have "fluent in Javascript" in their mind, so we had made a big progress for the IT consultants thanks to Struts ;-) )

Most of the (good) Java Joe developers where using Apache projects from the Jakarta line mainly as their sole Open Source use in corporate projects, and Tomcat was pretty much the sole Open Source container that you could find in production.

At that time JBoss started to change the game by grabbing several Open Source fames and projects on board (Tomcat, and then Hibernate to name the most famous).
Back in 2002, it became fairly common to see "JBoss knowledge is a plus" in job descriptions for IT consultants. Open Source had started to play with sharks, and you had to play with it, following the "fluent in Struts" move.

Next in the pie, Eclipse went bigger and bigger, and Open Source projects that were used and presented in conferences were more and more backed by someone that could afford it.
At that time I boosted AspectWerkz by joining Jonas' first iterations, all that on my spare time, unpaid, for the fun of it, as most of the OSS committers, bringing my little Open Source load time weaving framework that I had started some month before (beSee on SF).

AOP and IoC started to gain in popularity, and Spring was doing its first moves. It became common to see "fluent in Hibernate" in job description, and I remember the first time I actually noticed it was in february 2003.

I have been pushing the AOP ball since that time as part of my BEA job, and Open Source was more and more playing with sharks. AspectWerkz was backed by BEA, AspectJ revealed to be largely backed by IBM as an Eclipse technology project, and sucessfull projects that you could hear about in conferences where almost all backed by a shark - be it a big open source community like Apache, Eclipse, ObjectWeb that can afford its own events, or by a commercial vendor like BEA, IBM or JBoss.
Even more, some projects happens to be backed by more than one shark. AspectWerkz and AspectJ is an evidence of it thru the AspectJ 5 merger.

Back in 2004 the Spring fame became a shark by its own thanks to a well shapped service model around Rod' Interface21, that obviously adressed (and still adresses) Java Joe developer needs.

Last year I was wondering when I would see a "fluent in Spring" requirement in an IT job description, and it happened this morning, on the same line as "Tomcat, JBoss, Hibernate" for a "challenging J2EE architect opportunity" (interested?).

I have the feeling that Open Source will not be anymore this hectic group of people working for free for the fun of it as that sound to be back in 2000. Open Source is becoming more and more a distribution channel or a big thing to take into account when thinking about return on investment. If you look closely at some open source projects, you 'll also realize that it is rather common that 80% if not more of the workload is handled by a group of people sitting on the same open space.

The recent deal (backed by concrete M$) done around Geronimo (project that was already backed by Apache) is yet another evidence. Open Source is playing with sharks, so you'd better love that. And if you do want to kickstart an Open Source project, you'd better think which shark will play with you if you want your jewel idea to sustain.

As a last evidence, almost every single IT service company in France finally spinned of an official department dedicated to Open Source, bridging the gap with "SSLL" models (french acronym for open source service provider, doing consulting only on OSS stacks) . I have noticed this trend those last few months (Devoteam, Atos to name a few).
This not to comment on the Eclipse phenomenon, with almost all software vendors joining it and shaping their product line in a new more or less anticipated direction.

Open Source is not anymore the thing you use to maximize revenues, or to make sure you recruit uptodate brains. It's the thing you have to play with straight within your strategy, no matter if you are a software vendor or an IT service company.

So what will be the next Open Source moves in the Java are(n)a ?
Happy Open Source thoughts !

(note: dates in that post are those I remember and might be approximations. Aside, the job opportunities I am talking about are all for the French market, so you may expect some delta)

EJB 3 and AOP: the EJB interceptor dilemna

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

In this post I present an implementation a subset of the EJB 3 specification (JSR-220) : the EJB interceptors. As of today no EJB 3 preview brings an implementation that seamlessly integrates with AOP, despite the concept similarities.

The proposed implementation is fully runnable out of any container, and introduce a specific extension to allow use of pointcut in EJB interceptors, thanks to AspectWerkz extensible AOP container.

Wants to know more about EJB 3 interceptors, and how they are closed to AOP or different from AOP ? Read more.

Should we consider EJB interceptor as AOP ?

As you may know, the EJB 3 specification (JSR-220) defines

Interceptors for EJBs (stateless, statefull and message-driven). If it might be a good idea to spread an answer

for the need of addressing cross-cutting concerns in J2EE and EJBs in particular, it might be a bad idea to do it for

those of us (more and more numerous) familiar with AOP implementations like AspectJ and

AspectWerkz, especially because huge limitations of what the specification

allows us to do with those interceptors - at first sight and excluding any vendor specific extension.

The most anti-AOP concept in the specification is that the EJB that wants interceptor have to declare it explicitly

using a @javax.ejb.Interceptor or @javax.ejb.Interceptors class level annotation - which breaks the obliviousness of

aspects. That in favor of making things explicit, which might be good for J2EE users.

Further on, the EJB bean itself can have a method that intercept its own business method ie the bean is the

aspect (that sounds like marketing isn'it ?). Well. That's a specification and is interesting in the sense that it

democratize a technology.
So what can we do to democratize AOP as part of the EJB 3 specification ?


@javax.ejb.Stateless
@javax.ejb.Interceptor("test.ejb3.MyInterceptor")
public class MyEJBIsTheAspect {

// business method
public int businessSum(int i, int j) {
return i + j;
}

// interceptor method within the bean (the bean is the aspect)
@javax.ejb.AroundInvoke
public Object interceptMySelf(InvocationContext ctx) throws Exception {
System.out.println("--> MyEJBIsTheAspect.interceptMySelf");
System.out.println(" method: " + ctx.getMethod());
for (int i = 0; i < ctx.getParameters().length; i++) {
Object o = ctx.getParameters()[i];
System.out.println(" args["+i+"]: " + o);
}
return ctx.proceed();
}

}


State of the art (not that much..) in JBoss and Oracle AS EJB 3 preview

After having a look at JBoss EJB 3 and
href="http://www.oracle.com/technology/tech/java/ejb30.html">OracleAS EJB 3 previews, I was even more disapointed.

Both of them are using a reflective based approach to invoke the interceptors. This means that

the performance of the interceptor will be bad, and that a
href="http://www.aip.org/history/heisenberg/p08.htm">Heisenberg effect will be inevitable and actually fairly big

(no wonder that ones will use interceptor to gather performance metrics and thus as soon as you observe the bean, you

are observing a different things than what actually happens).

Ones may say this is a microscopic view. It is. But when thinking about EJB 2 stories in the past a sound idea would be

to make sure we don't waste resources where we can avoid it. And thinking about JBoss history around AOP, that's rather

suprising that the EJB 3 interceptors are not cleanly integrated in their AOP framework. I personnaly consider that we

have enough technology around to make it far better, and far more consistent with AOP. Given the impact that AOP will

continue to have, ones would better figuring out how to do that now with EJB 3 - assuming that EJB 3 succeeds.

AspectWerkz extensible container value proposal to EJB 3 interceptors

I decided to give it a try with the AspectWerkz extensible container. As Jonas Bonér described it in a
href="http://www.theserverside.com/articles/article.tss?l=AspectWerkzP1">TSS article, AspectWerkz can be considered

as a generic AOP runtime platform, in which ones can hook in any kind of AOP/AOP like programming model. AspectWerkz

aspects are one, AspectJ aspects are another, and we have implementations for Spring AOP and AOP Alliance aspects. An

AspectModel answers three essential properties: what is the life cycle of the aspect, how to invoke

it and how the programming model exposes the closure with wich the user proceed.

It happens that the EJB 3 interceptor can be seen as a very simple AOP programming model in two ways:

• ones can define interceptor class. An interceptor (advice) is thus a @javax.ejb.AroundInvoke annotated method with a
  
  specific signature (no interface, no mandatory method name) within a class - the interceptor class (aspect).


• ones can define a @javax.ejb.AroundInvoke annotated method (advice) in the EJB itself (aspect): the bean is the
  
  aspect !


• the closure is defined with the interface javax.ejb.InvocationContext


public interface javax.ejb.InvocationContext {
public Object getBean();
public Method getMethod();
public Object[] getParameters();
public void setParameters(Object[]);
public Context getEJBContext();
public java.util.Map getContextData();

public Object proceed() throws Exception;
}


The value proposal I am bringing here with the AspectWerkz extensible container is the following:

• no reflection at all. See performance figure f.e at our
  href="http://docs.codehaus.org/display/AW/AOP+Benchmark">benchmark site


• seamless integration of the interceptors with the aspects. They are made "aspect" thanks to AspectWerkz and the
  
  other aspect model (AspectWerkz aspect, AspectJ aspect, whatever aspect model registered in the runtime) coexists
  
  nicely


• easy points for vendor specific extension:
  
  
  • real pointcut to narrow the matching of an interceptor method to a very precise set of bean methods
  
  
  • life cycle control for the interceptor class
  
  
  • supporting cflow(), args() and alike AOP semantics
  
  
  • introducing high performant hot deployment and undeployment of EJB interceptors
  
  


• "out of container" runtime available


• rich integration patterns: application preparation (like ejbc / appc for faster deployment) or seamless
  
  deployment

AspectWerkz extensible container details

To better understand how things will looks like, you need some background in AspectWerkz:

The first key part is "org.codehaus.aspectwerkz.transform.inlining.spi.AspectModel". We will provide two

implementations of it. One for interceptor class (the interceptor class is the aspect), and one for bean as

interceptor (the bean is the aspect).
The second key part is in integrating the EJB interceptor closure "InvocationContext" that defines the "proceed()"

method with the more general idea of "Joinpoint.proceed()" of the runtime. In short, this means that the interceptor

will be entirely part of the aspect chain, and if there is a transaction aspect to handle EJB transaction boundaries,

they will share the very same chain - as ones expects - thus making it easy for the implementation to organize

precedence rules (as define in section 3.5.1 of JSR 220 for example).
As we already wrote this transaction aspect for EJB 3 in a previous
href="http://www.theserverside.com/articles/article.tss?l=AspectWerkzP2">AspectWerkz TSS tutorial, that's rather a

simple idea and basic requirement.

The runtime will take care of aggregating the models depending on which aspect apply to which join point, each aspect

having its specific AspectModel and each AspectModel implementation being responsible for generating what it needs:


// a closure to deal with the join points
// ie models org.codehaus.aspectwerkz.joinpoint.JoinPoint interface
// to fit with the transaction aspect, or any other aspect
// and javax.ejb.InvocationContext to fit EJB3 interceptors
class jitEJB3Closure implements JoinPoint, InvocationContex
{

// the closure hosts state, optimization makes it more complex than that

// the target of the join point ie the intercepted ejb
// which is also third aspect: remember the bean is the aspect !
private MyEJBIsTheAspect target;

// first aspect in the chain, statically compiled
private TXAspect aspect_0;

// second aspect: the interceptor class
private MyInterceptor aspect_1;

// details skipped that makes those fields initalized as they should.

// as defined in javax.ejb.InvocationContext
public Method getMethod() {...}

// as defined in JoinPoint
public Class getTargetClass {...}

// other methods as per each aspect model affecting the join point
...

// generic proceed() method as defined in JoinPoint and InvocationContext
public Object proceed() throws Throwable
{
// sort of a loop to proceed with the advice chain

// case first round: TX aspect
// TX aspect
// as defined in the "AspectWerkzAspectModel implements AspectModel"
aspect_0.manageTX(this)
// "this" is considered as the JoinPoint instance

...

// case second round: interceptor class
// as defined in the yet to be written
// "EJBInterceptorModel implements AspectModel"
aspect_1.someNameOfYourChoice(this)
// "this" is considered as the InvocationContext instance

...

// case third round: the bean is the aspect
// as defined in the yet to be written
// "EJBIsTheAspectModel implements AspectModel"
target.interceptMyself(this)
// "this" is considered as the InvocationContext instance
...
}

}


That may sound a bit of gory details, but that's actually simple once you get the idea of this closure acting for

multiple AspectModel in mind. The code is actually 15O lines for the interceptor class model (EJBInterceptorModel)

and 25 lines for the bean is the aspect model (EJBIsTheAspectModel) thanks to some inheritance. It mainly deals with

• generating the InvocationContext methods (like getMethod(), getParameters())


• dealing with the EJB 3 aspect life cycle ie
  • 
    push the EJB instance on stack for the EJBIsTheAspectModel
  
  
  • create an interceptor class instance, bookeep it and push it on stack for the EJBInterceptorModel (as the spec
    
    does not specifies the life cycle, I will use a singleton model).
  
  

What about the deployment ?

I presented the runtime, but there is an interesting topic as well: the deployment. AspectWerkz pioneered the aop.xml to

define which
aspects are affecting the system. Obviously, we don't want that for EJB interceptor. We need to use the AspectWerkz API

to register what we need in the system. The interesting concept here is that we will transform what the EJB

specification defines thanks to annotation (@javax.ejb.Interceptor, @javax.ejb.Interceptors, @javax.ejb.AroundInvoke) in

real AOP pointcut that the AOP container understand.
That is where a vendor may easily hook in an extension (ie introduce a new annotation for example) to refine the

interceptor class life cycle, or to introduce a pointcut.

I am defining a class that will expose an API that will hide the AOP registration from the user or from the other parts

of our spec. implementation.


public class EJBInterceptorDeployer {

public static void deploy(String ejbClassName, ClassLoader loader) {
// step 1 - interceptor class

// read the ejbClass @Interceptor and @Interceptors class level annotation
// for each interceptor class name found as value of those annotation
// get the @AroundInvoke method information
// deploy an aspect
// using the EJBInterceptorModel
// to the pointcut : "execution(!@javax.ejb.AroundInvoke !static * " + ejbClassName + ".*(..))"
//

// step 2 - @AroundInvoke method of the bean itself
// find the @AroundInvoke method if any
// deploy an aspect
// using the EJBIsTheAspectModel
// to the same pointcut

}

// method making use of AspectWerkz aspect deployment API

}


The thing to note about the deployer is that it is not using reflection. It is f.e. using our
href="http://backport175.codehaus.org/">BackPort175 implementation to read the EJB annotations from the bytecode. If

we were not doing so, we would trigger the EJB class loading while our system is not yet defined,
and the weaver would not be able to do the job when using load-time weaving approaches.

What about running the system ?

In the sample application, I am deploying the EJB using the EJBInterceptorDeployer presented in the previous section.
In a full blown container I would hook the call to it when the application or EJB deployer would register the EJB in the

system.
The nice thing is that I can run my EJB and still have the interceptors when running as a standalone application by

using AspectWerkz load time weaving, and a simple static block to declare which class is an EJB.

The sample application can be run with (for ones familiar with AspectWerkz, there is no aop.xml..)


java -javaagent:lib\aspectwerkz-jdk5-2.0.jar test.ejb3.Sample



public class Sample {

static {
EJBInterceptorDeployer.deploy("test.ejb3.MyEJBIsTheAspect", Sample.class.getClassLoader());
}

public static void main(String args[]) throws Throwable {
// some one would do a lookup or inject for that when in the container
MyEJBIsTheAspect myEjb = new MyEJBIsTheAspect();

System.out.println("Calling the EJB");
int i = myEjb.businessSum(1, 2);
System.out.println("got : " + i);
}
}



AW EJB3 - Deploying test.ejb3.MyInterceptor for test.ejb3.MyEJBIsTheAspect
AW EJB3 - Deploying test.ejb3.MyEJBIsTheAspect for test.ejb3.MyEJBIsTheAspect
Calling the EJB
--> MyInterceptor.interceptStandalone
method: public int test.ejb3.MyEJBIsTheAspect.businessSum(int,int)
args[0]: 1
args[1]: 2
--> MyEJBIsTheAspect.interceptMySelf
method: public int test.ejb3.MyEJBIsTheAspect.businessSum(int,int)
args[0]: 1
args[1]: 2
got : 3


Conclusion

Though at first glance I found the interceptor part of the EJB 3 specification fairly odd, and was a bit sad that some

important AOP concepts like precedence and aspect life cycle, as well as expressiveness of the pointcut language are

completely sacrified, I must admit that it might help ones familiarize with AOP concepts.

It took 1h to implement the EJB 3 interceptor spec and have it perfectly integrated with AOP - unlike so far exposed EJB

3 previews by JBoss and Oracle (though those are actual preview, while this article is more a technology focus and

positionning).
It took 15 minutes more to implement a pointcut extension thru a new @org.codehaus.aspectwerkz.ejb3.AroundInvokeAOP

annotation, that allows me to reuse the expressiveness of the pointcuts ie a vendor extension:


public class MyInterceptor {

@AroundInvoke
@AroundInvokeAOP("execution(* *.businessSum(..))")
public Object interceptStandalone(InvocationContext ctx) throws Exception {
System.out.println("--> MyInterceptor.interceptStandalone");
System.out.println(" method: " + ctx.getMethod());
for (int i = 0; i < ctx.getParameters().length; i++) {
Object o = ctx.getParameters()[i];
System.out.println(" args["+i+"]: " + o);
}
return ctx.proceed();
}
}


Some more time would allow me to have further features, like f.e. supporting cflow and args pointcut, so that an

interceptor may look like an advice as it looks like in AspectWerkz aspects, with static access to intercepted method

arguments etc (ie no boxing in an Object[] array).

A next iteration would be to integrate with the AspectWerkz hot deployment feature, and this would bring in hot

deployment of EJB interceptors at no cost - while still having everything statically compiled for the runtime to perform

at its best.

This implementation may seems at first glance full of details, and perhaps like a hammer to address a simple part of the

spec. I don't think so. I think it address the very crucial point that so far everyone has skept - including

JBoss folks (that have a foot in the AOP trench): it integrates seamlessly with the aspects and AOP concepts, and

actually allow advanced user to apply more advanced AOP concepts as well ie bridging the gap between a commercial

concept and needs (EJB interception) and a sound concept backed by years of research (AOP and cross-cutting).

So which vendor will be the first to have its EJB play well with AOP : like applying an interceptor thru a real

pointcut, defining programmatic precedence etc, dealing with cflow and hotdeployment of interceptors, and all that with

an implementation that can scale ?

Want the source code ?
This one is part of AspectWerkz CVS.
It can be browsed from
href="http://cvs.aspectwerkz.codehaus.org/viewrep/aspectwerkz/aspectwerkz4/src/compiler-extensions/ejb3">here.

Side note: my feedback on the specication:

There are some odd things in the 3.5 section of the JSR-220 that I have spot:

• 
  - (sect. 3.5.1) an interceptor class or EJB can only have one single @AroundInvoke method (advice) in it, and its
  
  signature is (sect. 3.5.4) "@AroundInvoke Object someNameOfYourChoice(InvocationContext ctx) throws Exception". Why
  
  limitating that to having one single method in the interceptor class or EJB (sect. 3.5.1). My guess is that it is tied
  
  to the fact that precedence between advice would then be harder to define in the spec without new semantics.
  Then one might wonder why an interceptor is not defined as an interface with one single method "intercept(...)"
  
  that the EJB could implement as well. Having this interface would suppress the need for @AroundInvoke which sounds like
  
  an annotation overuse (unless it is a door open for vendor extension as I will do below..). I'll be interested in EG
  
  feedback on that topic, especially in regards of the first limitation.
  
• 
  - interceptor components life cycle is unspecified but stateless. That sounds like a very important and powerfull
  
  concept of AOP (especially AspectJ) that has been left aside. It is probably an interesting door to provide vendor
  
  specific extension ie thread safe interceptor, per bean class interceptor, per bean instance interceptor, per
  
  application interceptor etc (but then interceptor component may not be stateless anymore.)
  
• 
  - (3.5) an interceptor intercepts all business method (or MessageListener methods for MDB). This means that every
  
  interceptor will be poluted with a code snip like "if (invocationContext.getMethod().getName().equals("doSomething"))
  
  ..." ie ones will have to write sort of a pointcut in a very loosy way while AOP allow us to write that in a neat way
  
  (and further, a way that tools can easy understand to spot which method is intercepted by what).
  
• 
  - javax.ejb.InvocationContext is tied to EJB. What will happen when interceptors will end up somewhere else ?
  

Fortunately, the implementation exposed in this article addresses those issues nicely from a vendor specific extension

perspective.

Note: These are my own thoughts and not of my employer ..

BEA joins Eclipse

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

That's an exciting time for BEA.

We now have announced we are joining Eclipse with a number of interesting things in the pipe, ranging from AOP with the AspectWerkz/AspectJ effort leading to AspectJ 5, to the IDE part that will shape up BEA WorkShop, and leading positions in the Web Tools Platform, and in the JDT compiler area.

Things were a bit odd when we shipped an AspectWerkz Eclispe plugin some month ago, since everyone out there was thinking that there was a death match between BEA WorkShop and Eclipse... Didn't you thought that way ?

And don't say we have started to sneak in randomly just to catch up. Things are now ranging from the JVM with AOP work going on within JRockit up to the IDE...

Read the news
http://biz.yahoo.com/prnews/050222/sftu152_1.html

JUnit Test cases and number of tests ?

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Last time I was reading about a project, folks were arguing they had many many tests.

But what is exactly this measurement ? Do we have to count the number of classes that extend JUnit TestCase, or the number of test*(..) methods, or the number of calls to JUnit assert*(..) ?

The current figures for AspectWerkz are pretty much those one:
- 92 extends TestCase
- 544 test*() methods
- 1380 calls to assert*(..)

Off course, what would matter would be the coverage (that has several definitions as well), but still, the number of test in an interesting thing to define.

So how many tests do I have ?

Writting IDEA plugins

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Today Jonas and I shipped Backport175, a back port of the JSR-175, the Java 5 Annotations spec.

This project comes with an Eclipse plugin and an IDEA plugin, so its time to say something about IDEA...

I just like the architecture of the IDEA plugins. There is very few docs on the topic, some very bad javadoc, and some samples around but no books yet etc.
Anyway, you can find some help on the IDEA forums, and guys like the Groovy ones have written plugins as well, so you can find a bunch of code around.

The nice thing in IDEA plugins is that it s just code, a rather clear API, and a bit of IOC (IDEA is using PicoContainer). A plugin as just one XML descriptor.
For an Eclipse plugin, you need a lot of XML, find what are the extension point, and dig in the docs and books, and get familiar with the Eclipse plugin wizardry. The game is very different, while for IDEA, it s just an API that you have to get familiar with.

What is missing the most in IDEA v4 is a good plugin project wizard, but if you have the chance to give a try to IDEA IRIDA, the EAP of the upcoming v5, then you have it, and it's as easy to debug your plugin as it is for a regular app.
The great thing with IDEA is that you can write a very small Ant script to build the plugin. I would not even try to go there for Eclipse (perhaps I am wrong ...).

You can probably learn some in that space by comparing both Backport175 plugins. It will leads you thru
- how to have a menu of your own to add / remove the feature to a given project (nature / actions and menu)
- how to hook in in the build system (builder / compilation listener)
- how to deal with markers

Off course, it is probably not the correct design neither for Eclipse nor for IDEA (I am far from beeing efficient in that plugin area) but it seems to do the job.

IDEA plugin CVS
Eclipse plugin CVS

Thanks to JetBrains to allow free use of IDEA for OSS projects !

Spring pointcut on steroids

(imported from http://blogs.codehaus.org/people/avasseur, read comments 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 ;-)

AspectJ and AspectWerkz to Join Forces

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

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