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 !