AspectWerkz 2.0 RC1 is released.

Here is a short summary of the new features and enhancements in this release. For more details read the What is new in AspectWerkz 2? paper, or dive in into the online documentation.

The most important improvements are:

New architecture

• Fast: Average 20x faster architecture as compared to AspectWerkz 1.0
• Open: Extensible AOP container allow to deploy Spring AOP, AspectJ aspects and virtually any aspects in the same runtime
• Dynamic: Hotdeployment and undeployment of aspects thru a simple atomic API
• Simpe: Aspects can be written in plain Java, using Java 5 annotations or equivalent doclets for Java 1.3/1.4

Richer semantics

• Support for after returning and after throwing advices
• Access advised instance and advised member arguments direclty without any casting or unboxing
• New mixin model
• New Java 1.3/1.4 annotations model to minimize the migration effort to Java 5 annotation
• Pay as you go model, the overhead of an advice is dependant upon the use or not of reflective information vs explicit binding

Higher reliability

• Fully based on ObjectWeb's ASM bytecode kit
• Weaved code is entirely statically compiled (no reflection or unsafe casting and object wrapping)

You can download the distribution here

Congratulations to the AspectWerkz team! The new features, especially deploying aspects written in other AOP systems and alignment with AspectJ, are great. From the documentation, it looks like a new TSS article on AspectWerkz as AOP container is coming soon. I look forward to reading it.

My blog on this announcement: http://ramnivas.com/blog/index.php?p=12

-Ramnivas

Fast: Average 20x faster architecture as compared to AspectWerkz 1.0

Apparently I did something wrong because my microbenchmark shows RC1 being 100 times slower than 1.0
http://kgionline.com/articles/aop_1/aop1.jsp#aspectwerkz2RC1
AW team, could you please look at source code http://kgionline.com/articles/aop_1/aop_1_src.zip and explain what went wrong?

Fast: Average 20x faster architecture as compared to AspectWerkz 1.0

Apparently I did something wrong because my microbenchmark shows RC1 being 100 times slower than 1.0http://kgionline.com/articles/aop_1/aop1.jsp#aspectwerkz2RC1AW team, could you please look at source code http://kgionline.com/articles/aop_1/aop_1_src.zip and explain what went wrong?

Shouldn't you ask for help BEFORE publishing those microbenchmarks, Konstantin ? :-))

Fast: Average 20x faster architecture as compared to AspectWerkz 1.0

Apparently I did something wrong because my microbenchmark shows RC1 being 100 times slower than 1.0http://kgionline.com/articles/aop_1/aop1.jsp#aspectwerkz2RC1AW team, could you please look at source code http://kgionline.com/articles/aop_1/aop_1_src.zip and explain what went wrong?

Shouldn't you ask for help BEFORE publishing those microbenchmarks, Konstantin ? :-))

Maybe. But I like AW alot and I hope that my microbenchmark will help them improving AW much quicker than an email.
  
And I do not believe that I have made a huge mistake, because the same aop.xml and the same test/advice classes show much better performance in AW1.0.

I will gladly correct my mistakes and publish a warning that might prevent others from repeating the same mistake.

PS: I got an emai from AW and hope we will resolve this quickly. Stay tuned.

I'm a in doubt what aspect framework to use. I'm thinking about standarizing it into our build process. But which framework?

I get the impression both AspectJ and AspectWerkz are very good implementations, but both use a different syntax, and I really really don't like lock-ins on build process level!

Is there a way that someone (yooohoooo Suuuuhuuun) could arrange for a commmon syntax?

Note: a benefit AW has is that it is all plain Java, so no need for any special settings or steps in your build process. However you need some special VM options when you start up your application.

Note: a benefit AW has is that it is all plain Java, so no need for any special settings or steps in your build process. However you need some special VM options when you start up your application.

Hmmm, ok, but I think I prefer changes in the build process as opposed to in the runtime.

Note: a benefit AW has is that it is all plain Java,

This is a separate benefit and a distinction from lets say pure Javassis where aspects are textual scripts written in Java. It means that IDE goodies like code completion, syntax check etc. are available when for AW aspects and aren't available for pure Javassist aspects.
However this is not unique to AW, other systems provide the same benefit: CGLib, HiveMind, and JBossAOP to name a few.

so no need for any special settings or steps in your build process. However you need some special VM options when you start up your application.

Hmmm, ok, but I think I prefer changes in the build process as opposed to in the runtime.

In the case of nowadays AOP it really does not matter much and extra build step only affects startup time and allows using aspects when there is no way to supply JVM with necessary options.
Personally I have found dynamic AOP to be more convenient.

I would speculate that you just want to have more control over build process results and want to be certain what aspect were applied and where. IMO extra build step does not help here and might lead to problems (for example IDEs tend to recompile classes ‘at will’, so aspects get lost).

I would see benefits of extra build step if AOP system were based on simple codegeneration ( I wish they were ), so we could look at the actual sources. But that is not the case and that leads to a feeling of lost control.

My guess is that AOP systems will soon mature enough and we will trust them as we trust compilers. Till that moment I wish I have access to an API that will at runtime print a report of all aspects, which were applied to a particular class/method or just about all applied aspects in the system. That might help regaining feel of being in control.

I know a lot of developers are "warming" up to AOP and what it has to offer, but I've become increasingly disenchanted by the whole idea.

What ever happened to type safety, readability, and test driven development? Things like the composite pattern, decorator pattern, etc can offer the same kinds of features that AOP offers, but with the type safety and readability.

If I can't 'new' it in a main method and run some tests, I'm not really interested in using it in implementing any logic.

I would be interested in hearing how people are using AOP in their applications and why?

I know a lot of developers are "warming" up to AOP and what it has to offer, but I've become increasingly disenchanted by the whole idea.What ever happened to type safety, readability, and test driven development? Things like the composite pattern, decorator pattern, etc can offer the same kinds of features that AOP offers, but with the type safety and readability.If I can't 'new' it in a main method and run some tests, I'm not really interested in using it in implementing any logic.I would be interested in hearing how people are using AOP in their applications and why?

I certainly understand your concerns and advocate cautious adoption of AOP, however in its core AOP is nothing else than macroses on steroids. Think about it as textual insertion and runtime code generation. The only difference is macro-language: in C++ we would need define those code fragments and place macro calls explicitly in the source, with AOP we can define that a certain code should surround every gettter, or every setter or something like that pattern in this class etc.

Yes, type safety can be thrown away and AOP can be easily abused, but if senior developers control AOP usage then it is quite convenient and it increases code quality and robustness.

Another misleading thing about AOP is that AOP pictured as purely orthogonal and that weaved class are not supposed to know anything about weaving. IMO it is quite opposite: AOP is properly used if system designed with AOP in mind and classes expect to be aspectized.

This is a simplistic view of AOP but works OK for a start. And to get taste of AOP you do not need to throw away type safety and convenience of IDE with all the code completion, syntax check and coloring. AW, HiveMind, and CGLib allow coding aspects as plain Java classes, which is very convenient.

You may read first part of my article (http://kgionline.com/articles/aop_1/aop1.jsp ) or look at another CGLib use for ‘pragmatic’ AOP here: http://kgionline.com/xflow2/doc/xflow2/code_tricks.html .

The same effect can be achieved with AW or HiveMind easily, but I think it is somehow easier to start with CGLib proxy based AOP and then employ a full blown AOP system like AspectWerkz as you get familiar with the concept.

I have few systems in the production, which use CGLib based approach and one that is HiveMind based and I am very glad that we used AOP concept.

Konstantin, thanks for the reply!

The only thing that's really perked my interest from what I call a 'business implementation' standpoint, is Alex Winston's AbstractModel blogs (www.alexwinston.com). But then I came to the realization that all he is doing is shortcutting 'code completeness' that can be done within a few clicks in an IDE (delegation).

I'm interested specifics in how people are using AOP to tackle mundane tasks that couldn't be accomplished through OOP?

I would have tackled the XFlow example you linked through delegation where the XFlow logic would depend on a Persistence object to be set in the constructor. That logic would be traceable and you still keep your SRP (Single Responsibility Principle). There would be no need then to instantiate your XFlow through some other means other than 'new'.

I would have tackled the XFlow example you linked through delegation where the XFlow logic would depend on a Persistence object to be set in the constructor. That logic would be traceable and you still keep your SRP (Single Responsibility Principle). There would be no need then to instantiate your XFlow through some other means other than 'new'.

That is almost exactly what is happens there. CGlib creates Proxy object that looks exactly as Persistence object and delegates all the calls to the instance of Persistence class itself. Every call is wrapped by IBatisMethodInterceptor#intercept( Object o, Method method, Object[] parameters, MethodProxy methodProxy ) where we make sure that expected ThreadLocal variables are initialized properly and that we propagate existing transaction and reuse existing session/connection ( see http://kgionline.com/articles/aop_1/aop1_html_m55596c3a.png ).
There is nothing fancy, just auto appliance of delegation pattern. That simply allows getting rid of tedious coding, that is it.

And the same thing could be done with XDoclet and plain old code generation, that is what I did before I discovered CGLib for myself.

There would be no need then to instantiate your XFlow through some other means other than 'new'.

That is exactly where AspectWerkz and other full-blown AOP systems shine.
They allow using 'new' and applying aspects transparently even to the classes, which do not expect it (famous AOP logging example). That is definitely more flexible but usage of Factory pattern makes AOP more visible and more explicit, which is a good thing IMO to get started with AOP paradigm and techniques.

That is exactly where AspectWerkz and other full-blown AOP systems shine.They allow using 'new' and applying aspects transparently even to the classes, which do not expect it (famous AOP logging example). That is definitely more flexible but usage of Factory pattern makes AOP more visible and more explicit, which is a good thing IMO to get started with AOP paradigm and techniques.

I guess that's good and all, I guess it comes down to what situation would *require* me to use something like AOP, and the only time I've run into an interceptor-type situation is within an application framework where they have their own way of filtering/intercepting calls that are specific to their protocols.