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.

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 !

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 !

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)