techno.blog("Dion")

Good ole Russ Miles has announced aUnit.

The big question, is how long will it take before we see aTest NG! :)

Hi everyone,

The first release of the source and binary distribution of aUnit is now available from www.aunit.org (via Sourceforge). This release contains a framework that piggybacks on the JUnit framework so it can take advantage of the existing JUnit integration with Eclipse. The aUnit framework executes a series of test steps that each present a representative context to the aspect being tested, executing the corresponding advice as required by the test developer.

This release relies on AspectJ 5M2 and Java 5 (due to the use of annotations) but in the next revision I’m hoping that we can put something together that works without the need for annotations (using something like the ASM to construct implicit contexts).

The important thing is that this is a working test framework now with a set of examples available in the source download to show you how to create aUnit tests. I’m now looking to put together some how-tos over the next week or so and then some more comprehensive tutorials as the feature set matures.

Thanks to everyone for their suggestions, especially that AspectJ team. Hopefully now aUnit can mature into something truly useful.

Have Fun and any support in the development of aUnit is greatly appreciated!

Cheers,

Russ Miles

Ramnivas is ready to take you to other dimensions in part two of his articles in the AOP@Work IBM developerWorks series: AOP and metadata: A perfect match, Part 2: Multidimensional interfaces with metadata.

In the first half of this article, I introduced the basics of the new Java

The AspectJ train keeps rolling. The team has announced the second milestone release:

We’re pleased to announce that AspectJ 5 M2 is now available for download at

http://www.eclipse.org/downloads/download.php?file=/technology/aspectj/dev/aspectj-1.5.0M2.jar

The changes in AspectJ 5 M2 since M1 are numerous, and the highlights are listed below.

* Full source compilation of Java 5 programs (with the “-1.5″ option)
* New Xlint warning when advice does not affect any join points (and the @SuppressAjWarnings annotation to suppress it) (-1.5 only)
* @this,@target,@args forms changed from @this(@Foo) to @this(Foo)
* Full support for annotation binding as context in @this, @target, @args, @annotation, @within, @withincode
* Declare annotation (declare @field, declare @method, declare @constructor, declare @type)
* Declare soft does not soften runtime exceptions
* pertypewithin instantiation model
* performance improvements resulting in reduced compilation times
* aspectpath has been extended to accomodate directories as well as jar/zip files
* many, many bug fixes

The AspectJ 5 Developer’s Notebook has been updated to reflect the updates. So many people have contributed ideas, suggestions, and bug reports to M2 that it’s impossible to list you all – but you know who you are, so thank you. Come 1.5.0 final we’ll put together a roll-of-honor :)

For examples of some of the new features in action check the following links:

* http://www.aspectprogrammer.org/blogs/adrian/2005/03/event_driven_ar.html
* http://www.aspectprogrammer.org/blogs/adrian/2005/03/ramnivas_on_ann.html
* http://www.aspectprogrammer.org/blogs/adrian/2005/01/making_concurre.html

and also the AspectJ 5 Developer’s Notebook: http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc/ajdk15notebook/index.html

Thanks and stay in touch,
The AspectJ Team.

Some of these features are really great. I love the @annotation stuff, and the pertypewithin instantiation model.

aspectpath has been updated. I wish that these classpaths could be directories that CONTAIN .jar files too (as many people have wished).

Competition is the mother of invention. After SQL AOP was invented, Cameron quickly came out with A-SQL. Both projects have common goals (bringing AO to the DB world), but we have different philosophies.

So, I quickly realised that some of the concepts that were placed in SQL AOP also fit nicely with XML. I have to give some of the credit to Hibernate 3, which has been called an ORXM rather than just an ORM.

I want the ability to modularize my XML cross cutting concerns, just like I do with my SQL ones. Luckily, we have great features such as Schema to help me out. Anyone who has worked with ref’d in XML can attest to this.

In fact, I have started to eat my own dog food here. Instead of using <preGoal> with Maven, I am using <before> SQXML advice.

I also feel that with SQXML AOP, we do not have the need for SDO, as this merger of SQL and XML can handle Web Services automatically.

Take that Cameron :)

:)

Rickard has written up Thoughts on Senselogic and SiteVision.

He has been a lot quieter since starting Senselogic… and this explains why. It is a lot of work!

I know how that feels.

It is interesting to hear about his thoughts on AOP. I think everyone wants to see the great tools he has ;) Maybe he can help get them in New AspectJ.

Michael Howard is on a security team at Microsoft. He is the author of Writing Secure Code, and he spoke to us about the security scene at Microsoft.

The #1 agenda at MSFT used to be “app compat” (NOTE: There seems to be a sub-culture at MSFT that uses different terms :), but now security has taken over the top spot.

To enforce this, Michael and his team came up with a new software development process. He detailed this in front of us all.

I asked him about AOP, and he said that he hasn’t thought about it.

To me, enforcing security policies is a perfect example of AOP. A lot of the AOP work that you can get into places, starts off with this style. You write some nice aspects which modularize your policy, and then developers aren’t able to trip up.

This should be the same way in MSFT. If I develop something which doesn’t meant the secure code guidelines, when I do a build, I should get a warning.

This is a much better idea than going through code at the end of the process.

Of course, these policies may not be able to 100% capture the cross-cutting security concern, but they can surely do some of it!

Come on Michael, take it to the next level ;)

AOP adoption requires a good standard aspect library.

Throughout AOSD, and indeed after the show (including on Saturday), a group gathered to discuss a new AOP library. The group consisted of the group of people named above, and other users of AOP. The first meeting discussed the scope of the project. Since we had multiple implementors (AspectJ team, and JBoss AOP for example), what could be used by both. It was really great that Bill had time to be there, as we discussed that, at a minimum, it would be good to share annotation naming/semantics. From there, pointcut language could be reused too, and potentially even more.

The bulk of the code itself will be written using the common idiom of AOP:

• Java code where possible, doing the actual work
• AspectJ code to do the thin wiring up to the Java modules

This also means that there is potential reuse outside of the scope of an AspectJ 5 library.

Rob Harrop of Spring was also key at these meetings. The library does NOT want to reinvent the wheel here. We have common issues such as configuring Aspects, and the default DI implementation will be Spring for this goal (Although, we talked about how we will also tie into hivemind, pico, and the like).

Spring also offers a lot of logic that we can reuse. Take a set of Transactional aspects for example. Spring has a LOT of code to handle transactions, from XA to Local, to Hibernate, to JTA, and beyond. We definitely want to just write aspects which USE these features.

On Saturday, the team ironed out a beginning taxonomy for the aspect library. Then we got to answer the age old question:

How many AOP experts does it take to come up with a reusable Tracing aspect.

The aspect library will be structured with two projects. One will be an incubation project that lives outside of the Eclipse foundation. Then, aspects will ‘graduate’ into the main AspectJ library itself which will be part of Eclipse.

A strong AO library will take AOP to the next level. The aim is to move people to using a lot of useful aspects, rather than thinking about writing everything from scratch. Imagine not having the Collections package in Java? We need a platform rather than just a language.

There has been a lot of interesting talk surrounding VM technology at AOSD.

JRockit Rules

Firstly, as Bill writes, the latest JRockit work is awesome. Why bother using a third party tool, when you can just download the JRockit JVM and have at it. The overhead is really meant to be almost unnoticeable, the metrics are fantastic, and the memory leak tool blows you away.

If you are on Intel, I think that you will be running on a JRockit JVM. And, they are working on other platforms too. I really want the JRockit team to do a screencast that we can put up to show you how cool this stuff is.

Microsoft Phoenix

Anders and company may be on the fence wrt AOP at Microsoft, but there were some other smart folks working on Microsoft Phoenix:

Phoenix is a software optimization and analysis framework that is the basis for all future Microsoft compiler technologies. The Phoenix framework is an extensible system that can be adapted to read and write binaries and MSIL assemblies, represent the input files in an IR which can be analyzed and manipulated by applications by using the Phoenix API and then the code can be written in binary, or JITable form for execution.

I saw a short presentation at AOSD and it looks very cool and promising.

I wonder if Sun will finally think seriously about getting AOP into their JVM ever.

With Microsoft and JRockit on the case, I think at some point they will have too. It just makes so much sense.

In fact, Sam Pullara talked a lot about AOP in the JVM in a session earlier today. It enables so many things, and will be a god-send to many of us. It will also make us think *very* differently about AOP.

Sam talked about how we will stop using the term “weaving”. At this point, we will be giving code to the VM. With AOP semantics. And it will be able to run the code correctly. It won’t be ‘weaving’ at all.

I think this is one of the reasons that many AOP-ists like to get the point across that AOP != interception, or “weaving”, etc.

Who knows how long it will take to get there, but I can’t wait.

The use, and development of Annotations will increase the use of AOP

Why do I say that? I think it makes sense from what we are seeing happen.

Right now, if you develop your own annotation, how do you actually DO something with it?

• Suns APT tool (source only? come on.)
• Reflection
• Write a quick Aspect :)

I naturally move to writing a simple Aspect to handle the work for me.

We are seeing these thoughts via:

• Bill Burke and JBoss have pioneered some of this thinking. Have Annotations as a nice way for users to get things done which happen to be using AOP below. And, then allow them to EXTEND using AOP themselves if they need too.
• Adrian’s Event Driven example
• Ramnivas’ thoughts 1, 2, 3
• Sam Pullara also had an example showing just how simple it is to put together a small DSL via a quick annotation and an Aspect, including an @Aspect

Sam also pointed out the similarity between this model, and JView/JDirect from the Microsoft JVM.

/** @dll.import(”URLMON.DLL”, unicode) */

private static native int FindMimeFromData(String prt, String URL, byte[] pbuff, int bufsize, String prop, int dmimeflag, int[] pout, int res);

Wait a minute. Doesn’t this look familiar? :)

The AspectWerkz team has released AspectWerkz 2.0 final.

AspectWerkz 2.0 final comes with bug fixes.

• option -keepjp renamed in -genjp (generate jit join points) (affects offline mode)
• perJVM mixin deployment-model restablished
• after returning advice was not handled properly in some cases
• issue with around advice and set() pointcut could happen with long/double fields
• issue with serialization and advised classes not implementing directly java.io.Serializable
• issue could happen when using hot re-deployment of advised J2EE applications

Read more and download

What’s new in 2.0