This post originated from an RSS feed registered with Java Buzz by dion. Original Post: AOP Library Meeting Feed Title: techno.blog(Dion) Feed URL: http://feeds.feedburner.com/dion Feed Description: blogging about life the universe and everything tech Latest Java Buzz Posts Latest Java Buzz Posts by dion Latest Posts From techno.blog(Dion)

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.