I've heard a number of people saying that "AOP is too hard", or "AOP makes things too complex". In a way this article was written as a rebuttal of those views (hence the title, "Simplifying Enterprise Application Development"). I mean, the whole point of AOP is that you take software that was getting complex and tangled up, and you simplify the implementation by giving each module a single responsiblity again by introducing aspects. And then of course for some requirements that are naturally expressed in a crosscutting way, it's much simpler and easier just to implement them with an aspect in the first place. The article shows how this process works, and lays out an adoption roadmap that counters the "AOP is too hard" argument - at each step along the way you can get a lot of value without having to become an AOP guru.

It's also a good introduction to the facilities offered by Spring AOP in the Spring 2.0 release.

We had a bug reported on the aspectj mailing list this week, in which a simple program returning a boolean value would return "true" when the code clearly said to return "false". Oh, and this only happens when running on the JRockit VM.

They say variety is the spice of life. This time last week I was just about to deliver a keynote at the SpringOne conference on the vision for the future directions of the Spring framework. One week on, and I've just finished an in-depth investigation into our bytecode generation strategies and their effect on the JRockit VM. A detailed write-up of the issue, my investigations into the situation, and the eventual resolution are documented in the AspectJ bug report that you can read here: 148007. The episode raises a number of interesting discussion points.

Firstly, it's interesting to see how different compilers generate code for the same or very similar Java program. In the bug report you'll see the difference between javac and the jdt compiler in compiling a very simple method (the jdt compiler varies again if you don't pass the -inlineJSR flag). There are many valid strategies for compiling program instructions into bytecode.

Secondly, VMs can have bugs in them (and so can compilers!). It sounds so obvious when stated, and you should certainly always be suspicious of your own code when something is not behaving as expected, but many people don't realize just how sophisticated (and hence complex) a modern JVM is.

Often the bugs are in corner cases. For example, I found and fixed a bug in the AspectJ compiler earlier this week in which an abstract generic aspect with a type parameter or paremeters that specify upper bounds, extended by an abstract generic sub-aspect that also specifies a type parameter with an upper bound and binds the super-aspect type parameter to it, could trigger a compiler message saying that the sub-aspect's type parameter did not satisfy the bounds of the super-aspect parameter, when in fact it did. The bug I'm discussing in this blog entry is significant because it's so near the mainline code path.

In essence, some perfectly legal and simple code strategies for compiling a method that looks like this:

private boolean invert() {
  try {
     return !isTrue();
  }
  finally {
     SomeType.doSomething(); 
  }
}

private boolean isTrue() {
  return true;
}

cause the JRockit VM (1.4.2_08, as used in WLS 8, I haven't tried in the 1.5 JRockit VMs) to return "true" from the invert method - when clearly it should return "false". This is one of those horrible category of bugs that just silently do the wrong thing (if the JVM were to crash, it would be much better in this case). Note that the set of circumstances needed to reproduce the bug are still relatively narrow :- must return boolean not Boolean, the negation is needed, the finally or some similar block is also needed.

The situation is not quite as simple as the code I've shown above, because the real bug report involved an aspect. So the program code was:

// in some class

private boolean invert() {
   return !isTrue();
}

private boolean isTrue() {
  return true;
}

// compiled with aspect
public aspect AnAspect {

  after() : execution(* invert()) {}

}

which the weaver translates into a program that looks like the first example I gave (note that I'm discussing implementation details here, not language semantics).

So the third interesting point - and the key lesson for any of the many projects springing up that use class file transformers, asm, cglib, or any other bytecode transforming tool. You always want to generate code that looks as close as possible to the code that javac would generate in the same situation. Even if you are generating perfectly legal bytecodes, straying too far from the javac path can uncover bugs in VMs. This is what was happening in the case under discussion - AspectJ was generating a bytecode sequence (perfectly legal) that looked subtly different from what javac would do. Enough to trigger what seems to be some kind of stack corruption bug in JRockit. (Remember that the same code works perfectly on every other VM we've tried). If you're writing, say, an ORM tool, you need to know not just the SQL dialects and semantics of the various databases, but also all of the undocumented bugs and quirks that you need to work around. It's the same if you're doing any compilation or bytecode generation for the JVM - you need to know and work around all the little quirks and bugs in the various VMs. Coder beware!

So finally, let me finish up with a plug for AspectJ. If you need to advise types in some way, AspectJ offers a programming model with a much better level of abstraction than writing your own transformers at the bytecode level. You're not restricted to forcing users to work with AspectJ directly - we offer classloader and class file transformer integration too. You'll be more productive using the AspectJ programming model, and you'll benefit from a compiler/weaver that's being widely used and works around known VM bugs etc.. (The bug report that triggered me to write this entry was very exceptional, and the AspectJ compiler now generates code that avoids the JRockit bug (good news for those using WebLogic Server)).

There's one more good reason for building on AspectJ - AspectJ has well-defined semantics for what happens when you weave types with one set of aspects, and then weave again with a second set. This mirrors for example the scenario where two class file transformers from different third parties are used in conjunction. If you don't build on top of something that offers this kind of semantic guarantee, what exactly is supposed to happen when your class file transformer is used in conjunction with someone elses? The semantics can only be "undefined" - which doesn't seem a good deal for users or for vendors...

Last week was the first public running of the course, in Oslo, Norway. I ran a two-day training (a nice way to verify a subset of the material - the full course is four days long). I had a really good bunch of students - most with little AOP experience but one or two who had done quite a lot with AspectJ. They all seemed to enjoy it, and everyone said they learnt lots (even those who had worked a lot with AspectJ before). I was really pleased with the learning from the students: it's my style to fire out lots of questions and get people to think and interact - they were producing correct answers to questions that I know have stumped many users on the aspectj lists, and this after only 1 day of training! The course had a lot of hands-on labs too: (a), it gives me a little respite from talking all day, but the real reason is (b) I believe that doing it for yourself really reinforces the learning. Labs are a potential nightmare for running a course, but this time everything passed off smoothly: the students had running web apps with AspectJ load-time weaving and Spring AOP all working together after no time at all. Kaare did his best to persuade me that maven 2 could make that set-up even easier. Maven 2 is definitely something I need to look into more...

As if giving 5 talks on the first day of the course wasn't enough, I also gave a talk to the Norwegian JUG in the evening. Lots of people gave up their evening to come and hear it, which was really nice to see. I thought I'd be tired after a whole days' teaching (and I was), but the atmosphere in the room lifted me and I had a really good time. There's a great crowd over in Oslo and if you get a chance to go to one of their JUG meetings you should take it.

This week I'll be giving a keynote at the SoftDev 2.0 conference in Stockholm, and then I'm speaking at the JAX conference shortly after that, so maybe I'll get to meet some of you at one of those two events.

If you like the sound of the AOP course, the next offering is in London on the 31st May. Contact me for details if you are interested.

So... let's take a step back here. Graham is positioning for container-based "AOP", which he appears to interpret as use of annotations that your container understands, in order to provide interception. Hmmm. What annotation-based container have Sun been working on recently I wonder? EJB 3 perhaps?? I predict that Graham will soon be telling us that Sun have solved all of our AOP needs within the safety of the JSR process, and all we need is EJB 3 with its @AroundInvoke and friends. Sorry Graham, @AroundInvoke != AOP either, by a very long chalk.

If you want container-based AOP, check out Spring AOP. What we had in Spring 1.x was way ahead of any @AroundInvoke style mechanism. What we've got in Spring 2.0 is two generations of technology ahead, and quite simply the best container based AOP there is (IMHO of course). I'll be talking about some of this in my TSS Java Symposium presentation later this month for those who are interested and will be in Vegas.

In "the bad" Graham takes a line of argument that "side files" and "runtime mechanisms" modify the semantics of the JLS. "Arbitrary intervention" with "arbitrary side effects" is a "quick race across the boundary line to insanity". Provocative wording indeed. AspectJ is a language. It's program constructs have semantics. There is no "arbitrary intervention" or "arbitrary side effect". The "side files" are source files written in the AspectJ language (it's kind-of normal for a language to have source files). AspectJ does support load-time weaving, which can link aspects with compiled classes at load time, but this has exactly the same well-defined semantics as the most common way of using AspectJ: compiling source files using a compiler that honours the semantics of the language by translating source code into a lower-level representation that is then interpreted by the JVM. If Graham doesn't like that idea, I guess he doesn't like javac either?? I think the underlying point that Graham was really trying to make underneath all the sensationalist language is the oft-heard assertion that aspect-oriented programs make it harder to understand what the program does. See the developerWorks article AOP myths and realities for a response to that point. Readers should also check out Gregor Kiczales' comment on Graham's blog. The truth is, as Wes Isberg recently reminded me "it's *all* an illusion anyway. Even the beloved JLS semantics.

Any technology, any language, can be used in an inappropriate manner and thus cause problems. The question is, does a technology or language make it easy to do the right thing, and in so doing give benefit to its users? I thought I'd let some of the posters to TSS over the last month have the last word on this...

On JBoss Cache:

JBossCache is a good example. We use AOP to implement the following cross-cutting concerns:
- Locking, depending on whether we use pessimistic or
  optimistic, we use a different interceptor
- Replication. If the cache is local, the
  ReplicationInterceptor is not present
- Invalidation. simply replace the ReplicationInterceptor with
  an InvalidationInterceptor (of course all interceptors are
  assembled by the cache at startup time, this does not have
  to be done by the user)
- Cache loading and cache storing
- Statistics. If disabled, the interceptor is not present
- Transactions

We even open the chain of interceptors up, so devs can insert their own
 (auditing, security etc).

The first version of JBossCache did *not* use AOP, and it became hard to maintain code that 
have to cover all permutations of 'aspects', e.g.
- transactional asynchronously replicated cache
- non-transactional local cache
- non-transactional synchronously replicated cache
etc etc etc

We already reaped the benefits of the refactoring: when we added optimistic locking, 
we simply replaced 1 interceptor.
JBossCache would today be unmaintainable without AOP.

On AOP in enterprise systems:

I've used AOP for several functions in enterprise systems:

- performance monitoring 
(see http://www.ibm.com/developerworks/java/library/j-aopwork10/ for my article 
that shows how this works in detail)
- macros & user feedback in a rich client app
- fine-grained (data-level) authorization
- error handling (isolating, summarizing, and consistently responding to errors)
- testing

In each case, AOP let us write clean code that's noninvasive and separately testable. 
By contrast, if we had scattered and tangled the implementation of these requirements 
it would have been virtually impossible to be consistent and correct. I think the AOP solution
is far preferable to the code generation, boilerplate templates, and heavyweight, and 
inflexible frameworks that people traditionally reach for to cope with these kinds of problems.

On reuse across projects:

> No AOP is only good for logging and tracing. Its a techy toy that will cause serious
> trouble and should be banned from any enterprise environment because of the 
> maintainance issues it will undoubtedly create down the line.Show a good example 
> where we would really use it

Wrong on all counts. We use it for
   Security
   Profiling
   Caching
   Transactions
   and soon
   Messaging
   Unified exception handling.

As usual, the only people who seem to berate never actually used it.

Oh, I almost forgot, all those items are reused across currently six different projects and 
NONE affects the business logic.

On the learning curve::

I have the opposite experience. AOP terminologies and syntax many feel strange initially
 (as is the case with any interesting technology). However, in my experience, most 
developers understand them quite easily.

I present AOP/AspectJ at many No Fluff Just Stuff and other conferences. I have a pretty 
uniform experience that most attendees understand the power, concepts, and syntax 
fairly well. For example, after explaining a few simple pointcuts, I ask attendees to tell 
me syntax for more complex pointcuts. I am happy to report near 100% correct answers. 
To me, this is an indication that the syntax is logical and predictable.

The same experience is repeated with developers at client sites. Developers understand 
the concepts and syntax very quickly (perhaps because they are motivated by its potential
to solve the problems they are facing!). Granted, many don’t understand the full power and
implications of using AOP right after the first introduction, but that isn’t unexpected.
As the article explains, it does take time to fully fathom AOP, much like any other technology.

A new user::

I actually just started using it.

We have a fairly large object model, used by (right now) two very distinct applications.
Due to certain realities, one project needs to listen to certain properties and the other 
project doesn't. I used AspectJ (AJDT in Eclipse) to instrument the model with the proper
interfaces, defined the proper pointcut, and it's working beautifully.

Took ~ 1 day to get used to the 'new' terms. Took another to get used to the syntax. 
Now the property change stuff is used only by the app which needs it, with absolutely 
zero impact on the other app.

Reality check::

We have been using AOP as the foundation for our CMS/portal products for three years now. 
It's working great, we don't even use it for logging and tracing at all, and some of the 
stuff we do would be impossible without AOP, not because they could not be coded, 
but because they would be horrendously expensive to write and maintain.

We use it for asynchronous event handling, undo management (on the client), 
replication, transactions, security, caching, parameter validation, the entire object model
(in a way that would be more or less impossible to do without AOP), versioning of state, 
automatic persistence, locking, last modified timestamps, business rules, client/server 
synchronization, and lots lots more.

In other words, it is not "only good for logging and tracing", it is not a "techy toy", and 
it should most definitely not be "banned from any enterprise environment".

There are other things that definitely should be banned from enterprise environments 
though, such as yacking about things that one knows nothing about. Now, there's 
something that'll cause all kinds of problems down the line.

On the cost of implementation:

All good suggestions!

I have used AOP in pretty much all the scenarios you mention. In all cases, I found that 
the cost of implementation is reduced significantly. Often, many useful features that 
would not have been implemented due to sheer implementation complexity associated 
with them (automatic fail over logic, for example) become suddenly very attractive when
 implemented using AOP.

For the client side, I have seen Swing thread safety aspects saved the day for quite 
a few projects.

Some specific projects/products for the ideas you mentioned implemented using AOP: 
Audit trail: see: http://nearinfinity.com/products.html
Monitoring: http://www.glassbox.com/glassbox/Downloads.do 
(and http://www.ibm.com/developerworks/java/library/j-aopwork10)
<plug>
For authentication and authorization implemented using AspectJ, check out chapters 
from my book  (free download): http://manning.com/books/laddad/chapters. 
Also take a look at table of content for a range of problems solved with AOP.
</plug>

The bottom line is a quote from the article: "...the only way to find out whether 
AOP is a good addition to your development practice is to try it for yourself.
I suggest that you set aside one full day to experiment with AOP -- not by 
reading articles, books, or blogs, but by coding aspects for yourself. 
Doing that will let you form your own opinion of AOP, which ultimately is what 
really matters."

On AOP helping to keep the Java platform competitive:

The team that I am working with now created a framework based on Facelets, 
AOP (heavy use of AOP, AspectJ and Spring AOP), JSF, Spring and Hibernate. We can 
create a simple database web application in a fraction of the time it use to take with 
a fraction of the code. It is all Java based. We are in the process of getting permission
to write a white paper. This framework has built in support for 
pagination, filtering, etc. etc. And, you can augment with standard JSF, and Java. 
(Like RoR this framework is not for Amazon.com, but it fits a lot of web application 
nicely). Also since we are built on top of Hibernate we can easily add caching. 
Since we are using AOP, we can easily add just about anything really (IMHO).

If you have your own success stories with AOP, I'd love to hear them. If you tried AOP and it didn't work out for you, I'd love to hear about that too so that we can learn where we need to do better...

It was my turn to write the column this month.

I have to say, I enjoyed writing the piece more than I thought I would - amongst other things it made we really think about how I actually do use Eclipse, and whether I'm using it as effectively as possible. The original column can be found here. With permission, I'm making an English translation (strictly, the English original!) available here for those that don't read German. If you have any favourite Eclipse tips that I don't know about, please do let me know!

My Eclipse

I’ve seen a lot of different people using Eclipse over the last few years. Nearly every one of them was using Eclipse pretty much in its default configuration. My Eclipse looks quite different to that, and in this article I’ll walk you through a collection of hints and tips for getting the most out of the IDE for Java development.

I’ll show you how to get organized when working with multiple workspaces, multiple projects, and lots of jar files. I’ll show you how to configure the IDE to help you write better code, and how to organize the Java perspective for maximum efficiency. As you might expect, I’ll also give you a couple of hints and tips for working with AspectJ!

Getting Organized

Using multiple workspaces

I tend to have multiple workspaces on the go at any one time (about 8 at present having just done a quick check). I use different workspaces for each major project (or version of a project) that I’m working with. For example, right now I’ve got workspaces for AspectJ 1.5.1 development, the AspectJ 1.5.0 release branch, Spring development, a couple of demonstration workspaces I use when giving talks, a workspace I use when giving training courses, and so on. It’s not uncommon for me to have 2 or 3 eclipses open at the same time.

The first practical question becomes knowing which eclipse is which when looking at the task bar or selecting between open windows using Alt-Tab. I always launch eclipse from the command-line using a script. Passing the “-showlocation” flag adds the workspace location to the windows title bar so that you can easily see which window is for which workspace. I normally start Eclipse with a little extra memory too (I find it works a little snappier that way). A good default for launching Eclipse if you’re working with sizeable projects would be something like this:

eclipse.exe –showlocation –vmargs –Xmx512m > /dev/null 2>&1

(I use cygwin, and I find that Eclipse tends to dump nonsense to the console that I don’t want to see, hence the redirect).

Another problem with using multiple workspaces is keeping your preferences and settings up to date across all of them. There is no need to configure each workspace individually every time you create a new one! Get one workspace set up exactly how you like it, and then select File -> Export -> Preferences. This will create a file that contains all of your preferences settings that you can keep in (e.g.) your home directory. Whenever you create a fresh workspace, use File -> Import -> Preferences and you’re good to go.

(By the way, if you're adding plugins to the base eclipse set, see Colin Sampaleanu's excellent blog entry on how best to manage that).

Coping with lots of projects inside a workspace:

It’s also not uncommon for me to have a lot of projects inside a workspace (one project per module). This is where working sets can make a big difference. Take a look at how the package explorer shows my core spring training workspace by default:

It’s just a jumbled mess of projects. Working sets to the rescue! From the drop down menu at the top right-hand corner of the Package Explorer view click on “Select Working Sets…”. From here you can define logical groupings of projects. With your groupings defined, select “Show -> Working Sets” from the drop-down menu. Now the Package Explorer will look something like this:

Much better!

Sorting out the clutter inside a project:

When looking at an individual project inside the package explorer, all of the jar files on the project build path show up by default. Most of the time I find these just get in the way. Here’s how my spring development workspace looks with the jar files showing:

The list of jars goes on even further, and worse, there are additional folders that I do care about at the end of the list. Select “Filters…” from the Package Explorer drop-down menu and define a new name filter matching “*.jar”. This will hide all of these jars from view making it much easier to find what you really want.

Organizing jar files:

On the subject of jar files, if you have common groups of jar files it can be very effective to define them as “User Libraries” that can be named and added to a build path as a unit. You’ll find the settings page to define user libraries under “Windows -> Preferences…” and then select Java -> Build Path -> User Libraries.

Sharing projects with others:

To make projects easy to share with others (for example, checking into a shared CVS repository) make the maximum use of variables. Right next to the option to define User Libraries, you’ll find the option to define Classpath Variables. When adding an external library to a build path of a shared project, always define a classpath variable that points to the containing directory on your local machine (or just the jar file itself). Then you “extend” the variable when defining a build path entry. This way each user can define the variable appropriately for their own local environment, but the project settings can still be shared in the repository.

Using Eclipse for Java Development

Helping Eclipse to help you write better code:

I used to use a small editor font in order to see the maximum amount of code possible inside the Java editor window. A while ago I changed tactics. Now I use a larger font than normal – 14 pt bold. As a consequence, I can see a lot less code in the editor at a time. This helps me write better code.

Let me explain.

It’s natural to want to see a whole method in one go. Seeing less code on the screen at a time has the subtle effect of making me write shorter, clearer methods. It’s also easier to sit back and reflect on code, and easier to pair program and work with others. Give it a try and see if it works for you too.

Organising the Java Perspective:

It used to be that I was never satisfied with the width I’d set for the Package Explorer and JUnit views. Too narrow and I couldn’t see the package and type names properly, or the stack traces in a test failure. Too wide and the editor window would get crushed between the Package Explorer on the left, and the Outline View on the right. Especially if you follow my suggestion of using a bigger font this can be a real pain.

I found the answer in a combination of fast views and in-place views. Now my eclipse dedicates as much real estate as possible to the source code. I have no views on the right-hand side, and no views on the left-hand side. The views I typically work with are the JUnit View, Type Hierarchy View, Package Explorer, and Javadoc View. Open these views, right-click in the title bar, and select “Fast View”. By default fast views dock at the bottom of the screen, but it’s not as convenient to move a mouse up and down to open them as it is to left-to-right. Select the fast view bar and choose “Dock on… left”. You have now reclaimed all of the space on the left-hand side that these views used to take, and your perspective should look something like this:

Another hidden benefit of this mode is that you can make the views wider than they were before, so that you can see the content properly (or even better for e.g. JUnit and Search, set the orientation to "horizontal" from the context menu). You can also set the widths of each view individually (JUnit wider than the Package Explorer for example, which is a significant improvement). If you don’t like having to move the mouse across to open a view, I’ll discuss a solution to that in a moment.

Any views you may have on the right-hand side, just close them (for most people, this means the Outline View). Instead use the in-place views. Ctrl-O opens an in-place Outline View (over the top of the editor). It’s actually better than the more usual docked view because it supports type ahead to quickly find the member you are looking for. Along with Ctrl-O, you also need to learn Ctrl-T which opens an in-place “quick” type hierarchy. This is a really easy way to see all implementers of an interface for example.

A final tip on the subject of view arrangement. If you have a dual monitor setup (becoming very common in the client sites I visit) it is quite nice to undock the Javadoc view completely – just grab it and drag it right outside of your Eclipse window and onto your second monitor screen. Now you’ll have the javadoc permanently open as a reference tool while you work. (Yes, you can undock views in Eclipse now, a lot of people seem not to know that).

On the subject of key bindings, you can significantly improve your productivity in Eclipse by learning some of the basic keyboard short cuts for common tasks (and indeed, for some things in the Java editor that aren’t available from the menus at all). However it’s also true that some of the default bindings for common tasks are absurd: “Alt-Shift-X,T” to run a test case for example – one of the tasks you’ll be doing very frequently I trust. When using fast views, I also find it convenient to add key bindings to open the Package Explorer and JUnit views quickly without having to move the mouse at all.

I make the following changes to the default key bindings:

Now that you have Ctrl-R to run tests, it’s worth knowing that you can use this shortcut from within the editor when editing a test case, when a package is selected (to run all the tests in the package), when a source folder is selected (to run all the tests under the source folder), and when a project is selected (to run all the tests in the project).

Here are some of the other key shortcuts that I find amongst the most useful:

You’re already familiar with using the arrow keys (left,right,up,down) to move around within the editor. Using the arrow keys in combination with Alt, Shift, and Ctrl put a whole new set of capabilities at your fingertips:

Other useful keys (standard cut/copy/paste etc. not included as I assume you are already familiar with these):

AspectJ hints and tips

Eclipse has great support for aspect-oriented programming with AspectJ through the AJDT plugins. In this section I’ll show you how to set up projects using linked source folders, how to run JUnit tests with an aspect library using load-time weaving, and some things you can do with the Visualizer that you may not realise. See the AJDT site on Eclipse.org for a tutorial on using AJDT – this section just contains a few less-well-known pointers.

Before we start, if you’re trying out using fast views and closing all the views on the right-hand side, one of things you’ll be missing is the cross-references view from AJDT (with all of the advises and advised-by relationship information). You can either dock this at the bottom (alongside the console for example), or use the in-place quick cross references view (not a lot of people know about that!). It has a not-very-useful default key binding of Alt-Shift+P, I remap it to Ctrl+U (not many letters left to choose from!). Now just press Ctrl+U anywhere in the editor and get a pop-up view of the cross-references for the selected element. Press it again to get cross-references for the whole file. Perfect!

Linked source folders:

Linked source folders can be a great way to experiment with aspects on a project without touching the main (Java) project at all. Create an AspectJ project alongside the Java project that you want to work with. Put all of your aspects into the “src” folder of the AspectJ project. Now, inside the AspectJ project open the project properties (Alt+Enter, since we’re trying to wean you off the mouse!) and go to the Java Builder page, and then the “Source” tab. Click on “add folder” to create a new source folder, and then the “Create new folder…” button. Here you’ll see an “Advanced” button. If you press this, you’ll get the option to create a folder that is actually a symbolic link to another location. Use this technique to create source folders inside the AspectJ project that are symbolic links to the source folders inside the Java project you want to work with.

Now whenever you build the AspectJ project, you will get (in the bin directory of the AspectJ project) a woven version of the project files. You will also see any warnings or errors arising from your use of declare warning / declare error in this project. The “donor” Java project remains completely unaffected by this exercise. Any changes to the source files in the Java project are of course instantly visible in the AspectJ project (and vice versa). To get the best performance, you can now turn off incremental building for the AspectJ project (Project menu -> build automatically) and just build that project on demand using the AspectJ build button in the taskbar.

Load-time weaving

(See my entry on using an aspect libraryfor a more in-depth treatment of this)

If you’re using an aspect library (such as spring-aspects.jar that ships with Spring 2.0) it is very convenient during development to use “load-time weaving”. Load-time weaving is the name given to weaving your application classes at runtime as they are loaded into the virtual machine. In this way there is no need to convert your project to an AspectJ project, or to do anything special at all other than put the aspect library on your build path.

Say you have some integration tests that you kick off via JUnit, and that rely on the behaviour contributed by the aspects in order to pass. For example, you’re using @Configurable to dependency inject domain objects. With the needed library on the build path, create a launch profile for the test run. The easiest way to create a launch profile is just to highlight the test or set of tests that you want to run and run them with Ctrl+R (if you’ve followed my advice and remapped that key binding). This run will fail, because you haven’t activated load-time weaving yet. Now select “run…” from the launch menu and you’ll see the launch profile that was created for the tests you just ran. Click on the arguments tab, and in the “VM arguments” box add the following:

-javaagent:aspectj-install-dir/lib/aspectjweaver.jar

Where aspectj-install-dir is the directory where you installed AspectJ (it’s best to download the standalone compiler and associated tools from www.eclipse.org/aspectj when using load-time weaving, ant building etc..).

Now you can rerun the tests and you’ll find that AspectJ picks up and uses the aspect libraries that you have on your classpath. It really is as simple as that.

Visualizer:

One of the tools that you get when you install AspectJ is the Visualizer. In fact, you get a whole “Aspect Visualisation” perspective which is the best way to use the visualiser. By default, the visualiser shows you cross-cutting information such as advises and advised by relationships. The visualizer plugin actually provides a generic capability that is not tied to AspectJ though. Open the visualizer perspective, and from the drop-down menu of the main visualizer view select “preferences”. Here you can choose the data provider that the visualizer will use to display information. By default it uses the AspectJ provider as I said. If you change to the “JDT Search Results Provider” you can use the view to visualize the results of the current search (all the matches, and where they are in the project).

The following image shows the results of searching for references to “InitializingBean” in Spring. Just as with the advice visualization, you can navigate from the visualization to the source code locations simply by clicking on the bars.

If you select “Resource and Markers Provider” you can see where all of your breakpoints, Task markers, warnings and errors are. Clicking on the options in the visualizer menu enables you to choose the subset of these that you are interested in at the time:

And finally

If you haven’t done so already, you should check out the Mylar plugin for Eclipse (developed by one of the AspectJ team, Mik Kersten) (see www.eclipse.org/mylar, and then go to the getting started page and watch the flash videos there). Especially if you’re working with bugzilla, Mylar is fantastic. Mylar deserves an article all of its own so I won’t attempt to describe it here – just go and try it out for yourself, you’ll be glad you did!

Introduction

With the arrival of AspectJ 5 and the Spring 2.0 milestone builds, many of you will be working with AspectJ-based aspect libraries for the first time. This article is a practical guide to get you up and running as quickly as possible and with the least amount of hassle. I'll cover development and unit testing, integration testing and deployment, continuous integration, and production builds.

I'm assuming that for the time being you don't want to write your own aspects: you just want to use the capabilities of an existing library. As a running example, I'm going to use the aspect library that ships with Spring 2.0: spring-aspects.jar. This library contains an aspect that supports dependency injection of domain objects, following the principles I outlined in the developerWorks article "Dependency Injection with AspectJ and Spring" (http://www-128.ibm.com/developerworks/java/library/j-aopwork13.html).

The library supports an @Configurable annotation. When an instance of an @Configurable type is created, however it is created, it will be dependency injected by Spring. The following examples demonstrate some typical uses of the annotation:

@Configurable
public class Account {...}

When the annotation is used like this without a value, an instance of Account will be dependency injected by Spring, using the fully-qualifed class name of Account as the bean name.

@Configurable("accountBean")
public class Account {...}

When a value is supplied, it is used as the bean name: ;n instance of Account will be dependency injected by Spring, using "accountBean" as the bean name.

@Configurable(autowire=Autowire.BY_NAME)
public class Account {...}

An instance of Account will be dependency injected by Spring using autowiring by name.

@Configurable(autowire=Autowire.BY_TYPE)
public class Account {...}

An instance of Account will be dependency injected by Spring using autowiring by type.

When autowiring, it is also possible to require a dependency check by specifying dependencyCheck="true". For example,

@Configurable(autowire=Autowire.BY_TYPE, dependencyCheck="true")
public class Account {...}

So let's get started developing an application that uses @Configurable...

Development, unit testing, and simple integration testing

Unit testing means testing the Account class in isolation. The standard benefits of dependency injection as related to enhanced testability apply here, and there is nothing special to do. In unit tests, we will manually pass in mock or stub implementations of the Account object's dependencies.

You can annotate any type with @Configurable, but just using the annotation on its own doesn't deliver the behaviour associated with that annotation by the aspects in the spring-aspects library. You need to link (or "weave") the aspects in the library with your application for it to behave as desired at runtime. In this section I'm going to focus on what you need to do to get your basic integration tests passing in your IDE. I'll describe configuration for both Eclipse and IntelliJ IDEA. If you use a different IDE it should be straightforward to setup a similar environment.

First let's look at the sample project we'll be working with. The project defines one domain object, "Account", a service interface "AccountService", and a default implementation of that service, "DefaultAccountService". There is an accompanying test suite, "AccountTests". The Account class looks like this:

/**
 * Sample domain class using the Spring @Configurable annotation.
 */
@Configurable
public class Account {

    private AccountService accountService;

    public void setAccountService(AccountService anAccountService) {
        this.accountService = anAccountService;
    }

    /** so that we can test it has been set appropriately */
    public AccountService getAccountService() {
        return accountService;
    }

}

It is expecting to be configured with an "AccountService" when it is instantiated. The test case verifies this is the case:

public class AccountTests extends AbstractSpringContextTests {

    public void testAccountConfiguration() {
        Account acc = new Account();
        assertNotNull(
          "account service should have been provided",
          acc.getAccountService());
    }

    protected void setUp() throws Exception {
        super.setUp();
        getContext(new String[] {
            "org/aspectprogrammer/samples/domain/beans.xml"
        });
    }

}

Note that "testAccountConfiguration" simply creates a new Account object using the default constructor, and expects it to be dependency injected. The test case configures a Spring application context from "beans.xml". Here it is (using the new Spring 2.0 configuration style):

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	   xmlns:aop="http://www.springframework.org/schema/aop"
	   xsi:schemaLocation=
             "http://www.springframework.org/schema/beans 
              http://www.springframework.org/schema/beans/spring-beans.xsd
              http://www.springframework.org/schema/aop 
              http://www.springframework.org/schema/aop/spring-aop.xsd">

    <!-- this element causes spring to configure the
         AnnotationBeanConfigurer aspect in spring-aspects.jar
         so that it has a reference to the bean factory 
    -->
    <aop:spring-configured/>

    <!-- configuration of Account bean, because we don't specify an 
         id, the class name will be used as the bean name. This 
         conveniently matches the behaviour of @Configurable when no
         bean name is given in the annotation 
     -->
    <bean 
       class="org.aspectprogrammer.samples.domain.Account"
       lazy-init="true">
       <property name="accountService" ref="accountService"/>
    </bean>

    <!-- service used by the Account bean -->
    <bean id="accountService"
      class="org.aspectprogrammer.samples.services.impl.DefaultAccountService">
    </bean>

</beans>

You'll need spring-aspects.jar on the classpath for your project.There was a packaging issue with the jar in Spring 2.0 M1, but if you're using M2 or higher everything should work as described in this article. You'll also need the AspectJ runtime library, aspectjrt.jar on the classpath.

If we run the test case under JUnit right now it will fail with the message "account service should have been provided". This is because we haven't woven the application with the aspects in the library yet, so there is no behaviour associated with the annotation. So how do we make the tests pass?

Introducing Load-time Weaving

AspectJ is first and foremost a programming language. It supports constructs called "aspects" in addition to the regular Java types. So one way to use AspectJ is to write a program in the AspectJ language, compile it with the AspectJ compiler (producing standard .class files), and run it. AspectJ also lets you take pre-compiled aspects (in a jar file for example) and link (weave) them with your application classes. This can be done as an additional stage in a build process (see later) or at runtime as classes are loaded into the virtual machine. Weaving classes at loadtime goes by the name of "Load-time weaving" or "LTW" for short.

Load-time weaving is a very easy and flexible way to use an existing aspect library during development. The simplest way to use it is under Java 5 using the AspectJ weaving Java agent.

Using LTW with JUnit in Eclipse and IDEA

To set this up in Eclipse, do the following:

Click on the Run... drop-down icon in the toolbar to open the run configurations dialog. Click on "JUnit" and then press "New". Give the configuration a name (I've called it "tests") and select the tests you want to run (I've chosen to run all the tests in the project):

Click on the "Arguments" tab and in the "VM arguments" section enter:

-javaagent:lib/aspectjweaver.jar

The part after the ":" should be the path to your copy of aspectjweaver.jar. In this case, I've copied the aspectjweaver.jar from the Spring distribution into the lib directory of my project (it doesnt' need to be on the project's classpath). You can use the jar from the AspectJ 5 final release too if you want to.

That's it!

Save and run the configuration - you should see a green bar.

To set this up in IDEA:

Configuration in IDEA is very similar. Open the "Run/Debug Configurations" dialog using the drop-down in the toolbar. Click the "+" icon to create a new configuration and name it e.g. "tests".

For this project, I've selected "All in package" and search for tests "In whole project".

Now all you have to do is add the VM startup parameter that brings in the AspectJ LTW agent:

-javaagent:lib/aspectjweaver.jar

The part after the ":" should be the path to your copy of aspectjweaver.jar. In this case, I've copied the aspectjweaver.jar from the Spring distribution into the lib directory of my project (it doesnt' need to be on the project's classpath). You can use the jar from AspectJ 5 final release too if you want to.

That's it!

Save and run the configuration - you should see a green bar.

Running a Java application with LTW

To run a Java application (class with a "main" method) from your IDE you can follow exactly the same process and set the javaagent VM parameter. In Eclipse if you have the AJDT plugin installed, there is also a dedicated launch type that gives you a few more options here.

In the run configurations dialog, create a new "AspectJ Load-Time Weaving Application" launch configuration.

You'll see a new tab appear, "LTW Aspectpath". By selecting that tab you can add aspect library jars from your project or from an external source, and even aspects that are built by another project in your workspace.

This can be a very convienent way of launching an application with a diagnostics or instrumentation aspect library for example. Remember that this all works with standard Java projects - you do not need to convert your project to an AspectJ project.

Getting more information

So how did that work?

AspectJ's load-time weaving agent is configured by the use of aop.xml files. It looks for one or more aop.xml files on the classpath in the location "META-INF/aop.xml" and aggregates the contents to determine the weaver configuration. If you look inside spring-aspects.jar, you'll find a META-INF/aop.xml file in there that defines the Spring aspects in the library to the weaver. (For full details on the aop.xml file format and load-time weaving in general, see the AspectJ Developer's Guide).

Because aop.xml files are aggregated we can define our own project file and use it to give additional instructions to the weaver. One useful option to pass is "-showWeaveInfo" which causes the weaving agent to tell us exactly what it is doing.

Create a META-INF folder under the source root of your project (e.g. "src/META-INF"). In that folder, create a simple aop.xml file as follows:

<aspectj>
    <weaver options="-showWeaveInfo"/>
</aspectj>

When you run the tests again, take a closer look at the console output. Here's the edited output of running the tests on my machine (I've stripped the package names out for clarity):

23-Dec-2005 13:45:08 AbstractSpringContextTests loadContextLocations
INFO: Loading config for: org/aspectprogrammer/samples/domain/beans.xml
23-Dec-2005 13:45:08 XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource 
      [org/aspectprogrammer/samples/domain/beans.xml]
weaveinfo Join point 'initialization(void Account.())' 
   in Type 'org.aspectprogrammer.samples.domain.Account'(Account.java:15)
   advised by afterReturning advice from 
   'org.springframework.beans.factory.aspectj.AnnotationBeanConfigurer' 
   (AbstractBeanConfigurer.aj:96)
23-Dec-2005 13:45:08 AbstractRefreshableApplicationContext refreshBeanFactory
INFO: Bean factory for application context  .....

Notice the weaveinfo message? AspectJ will tell you exactly what it is doing - which join points in which types are advised by which aspects. In this case, the "initialization" join point for the default constructor of Account has been advised by "afterReturning" advice from the "AnnotationBeanConfigurer" aspect (the advice is defined in the super-aspect AbstractBeanConfigurer, at L96 in the source file).

If you want the AspectJ messages nicely integrated into the log output (especially useful when it comes to deploying LTW in servers) you can supply your own message handler class using the "-XmessageHandlerClass" option. Spring supplies a message handler class that integrates the AspectJ messages into commons logging output produced by Spring itself. To use it add

-XmessageHandlerClass:org.springframework.aop.aspectj.AspectJWeaverMessageHandler"

to the weaver options in your aop.xml file. This class isn't supplied in the Spring 2.0 M2 distribution, but is included in M3.

Here's an extract from a test run using the custom message handling class:

23-Dec-2005 14:34:58 AspectJWeaverMessageHandler handleMessage
INFO: [AspectJ] register aspect 
       org.springframework.beans.factory.aspectj.AnnotationBeanConfigurer
...
INFO: [AspectJ] weaving 'org/aspectprogrammer/samples/domain/Account'
23-Dec-2005 14:34:58 AspectJWeaverMessageHandler handleMessage
INFO: [AspectJ] Join point 'initialization(void domain.Account.())' 
       in Type 'org.aspectprogrammer.samples.domain.Account' (Account.java:15)
       advised by afterReturning advice from 
       'org.springframework.beans.factory.aspectj.AnnotationBeanConfigurer' 
       (AbstractBeanConfigurer.aj:96)
23-Dec-2005 14:34:58 AspectJWeaverMessageHandler handleMessage
INFO: [AspectJ] weaving 'org/aspectprogrammer/samples/services/impl/DefaultAccountService'
23-Dec-2005 14:34:58 AspectJWeaverMessageHandler handleMessage
INFO: [AspectJ] weaving 'org/aspectprogrammer/samples/services/AccountService'
23-Dec-2005 14:34:58 AbstractRefreshableApplicationContext refreshBeanFactory
INFO: Bean factory for application context ...

Note that we're now also getting messages about the all of the aspects in use and all of the types that the weaver is looking at (the "weaving ..." messages). Of these, it is only the Account class in our project that has the @Configurable annotation, and hence it is only during the weaving of that type that we see a join point woven message.

Being able to get detailed information about exactly what the weaver is doing can be a useful aid in performance tuning and troubleshooting.

Controlling LTW with aop.xml

Controlling the weaving scope:

One of the things you might have noticed if you tried out the custom message handling class is that the weaver looked at a large number of types. This includes for example "junit.framework.TestSuite" and several other types in the junit package. Load-Time Weaving will be much more efficient if you scope it to just the types in your application that you actually want to weave. In the case of our sample application, that's the classes in the org.aspectprogrammer.samples package and sub-packages. The weaving scope is controlled by the aop.xml file. We can add one or more include and exclude elements to control the set of types that the weaver will look at. If there are no include statements, then the weaver will look at all types that are not explicitly included. If there are one or more include statements, then the weaver looks at all included but not excluded types. To weave only the sample application classes we can update the aop.xml file as follows:

<aspectj>

    <weaver options="....">
    	<include within="org.aspectprogrammer.samples..*"/>
    </weaver>

</aspectj>

The "within" attribute syntax is actually an AspectJ type pattern as used in the AspectJ pointcut language. For now all you need to know is that a pattern like "org.xyz.*" will include all types in the "org.xyz" package, and a pattern like "org.xyz..*" will include all types in the "org.xzy" package or any sub-package thereof.

Controlling which aspects are used:

The spring-aspects.jar contains several aspects. Since they are all defined by the META-INF/aop.xml file in the jar, they will all be registered and used for weaving. What if you want to use the @Configurable (AnnotationBeanConfigurer) aspect, but not the @Transactional support (AnnotationTransactionAspect)? You can control this via the aop.xml file too. This time you need to use the <aspects> element:

<aspectj>

    <!-- definitions of aspects available to the weaver, and which
         ones should be used or not used -->
    <aspects>
       <exclude within="org.springframework.transaction.aspectj.AnnotationTransactionAspect"/>

    </aspects>

    <!-- control over the weaver itself and the types that will be
         woven -->
    <weaver options="....">
    	<include within="org.aspectprogrammer.samples..*"/>
    </weaver>

The include and exclude options in the <aspects> element work the same way they do in the <weaver> element: if there are no include elements specified then all defined aspects that are not explicitly excluded are included. If there are one or more include elements, then all included but not excluded aspects are used.

What if I can't use Java 5?

For development, of course you can use Java 5!

By which I mean that even if you are developing an application that has to run under 1.3 or 1.4, you can still use a Java 5 VM with -source and -target compiler flags set appropriately. The only requirement to use load-time weaving in the way we have been describing is that you run the tests on a 1.5 VM.

In part II, I'll be looking at integration testing and deployment, and there I'll cover your options if you really can't use Java 5 to run your test server.

(Note: as mentioned at the start of this article, part II will be forthcoming just as soon as I get some more writing cycles!)

Firstly I'm always on the lookout for good books that I haven't read yet. If I see an interesting title that I've not read, I'll ask if it's any good.

Secondly, it tells me a lot about the background and mindset of the person I'm working with: you can often tell whether someone is interested primarily in the web-tier, data-tier, or domain modelling; you can tell what language they're likely to be familiar with when you're talking to them, and what technical background you can assume; you can tell whether they like abstract thinking or concrete how-tos. You can learn a lot from a few books...

The third reason is to guage how well different technologies are penetrating the marketplace. Seeing lots of "Pragmatic Ruby" books? That tells you that Ruby has made it onto the corporate developer's radar (it doesn't tell you whether or not Ruby is actually being used of course - you'll need to ask some more questions to find that out).

If I see books such as "Professional Java Development with the Spring Framework", "Pro Spring", and "Domain Driven Design" on the bookshelf that gives me a good feeling. The purpose of this entry is to highlight that there's a new book on the block I'm going to be looking out for: "POJOs in Action" by Chris Richardson. With a title like that, you may be unclear exactly what you're going to get. Rest assured, this is not a "lightweight" book - it has plenty of detailed discussion. The book is especially valuable for two reasons (maybe more!, but I'll pick on two here):

• It compares and contrasts different implementation techniques and approaches side by side. Want to see how dynamic paged queries pan out in iBATIS vs JDO vs Hibernate for example? Go to chapter 11. Same for detached object support, optimistic locking and more. There are also discussions on how to arrange business logic and the implications of EJB 3 ("if you are already using lightweight technologies such as Spring, Hibernate, and JDO you will be disappointed"). Too often in the software industry we tend to see things in black and white. The truth is that there are many shades of gray. When you see things put side by side and compared, you are better able to evaluate the strengths and weaknesses of different approaches, and the likely consequences of your architectural decisions.
• Chris encourages the reader to think for themselves, and not just rely on fashion and propaganda: "If we blindly used POJOs and lightweight frameworks, we would be repeating the mistake the enterprise Java community made with EJBs". (So here are the arguments for and against...).

I've only read part 1 and part 3 so far, but I've seen enough already to trigger that knowing smile if I see a copy of this on the bookshelf...

First some background for those of you who haven't been following along with developments in Spring 2.0. Spring 2.0 supports schema-based configuration as well as DTD based. Schema gives better validation, a better experience in the IDE (in terms of code completion etc.), and a more concise and readable configuration file. It's important to state that however you specify your bean definitions (DTD-based, schema-based, script-based,...) everything comes down to the same bean metadata model at runtime so the different styles are compatible and interchangeable. For AOP support, we have the schema http://www.springframework.org/schema/aop/spring-aop.xsd.

This is what a skeletal config file looks like using the new schema support:

<?xml version="1.0" encoding="UTF-8"?>
<beans 
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:aop="http://www.springframework.org/schema/aop"      
  xsi:schemaLocation="http://www.springframework.org/schema/beans   
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/aop
       http://www.springframework.org/schema/aop/spring-aop.xsd">

       
</beans>

The various AOP-related definitions are placed inside an <aop:config> element. Here's a cut-down example of a simple aspect from the test suite:

<aop:config>
  <aop:aspect id="beforeAdviceBindingTests" ref="testAspect">
    <aop:advice 
	kind="before"
	method="oneIntArg"
	pointcut="execution(* setAge(..)) and args(age)"
    />
  </aop:aspect>
</aop:config>

<bean id="testAspect"
      class="org.springframework.aop.aspectj.AdviceBindingTestAspect"/>

I'm declaring an aspect called "beforeAdviceBindingTests", the aspect instance (holding the state for the aspect) is the bean "testAspect". This is just a regular bean, that can be configured by Spring in all the usual ways. The implementing class (in this case, AdviceBindingTestAspect") is just a regular POJO. The aspect contains only one piece of advice, which is "before" advice (you can specify one of the five AspectJ advice kinds in the "kind" attribute: before, afterReturning, afterThrowing, after, or around). The advice body is implemented by the method "oneIntArg", and the associated pointcut expression matches the execution of any method named "setAge" taking a single int argument. The argument is bound to a parameter named "age".

What this all boils down to, is that any time a matching method executes on a Spring bean in the application context, the "oneIntArg" method will be called on the "testAspect" bean, passing the age as a parameter.

Note that we've gained two important things here: the aspect class and advice method do not need to implement any special interfaces, and we have typed advice. By typed advice, I mean that the advice signature declares the parameters it needs, and gets passed those parameters only, preserving type information. Contrast this to typical AOP framework approach of always passing an Object[] from which the advice body must pick-and-choose and cast as needed.

To complete this introductory example, here's the aspect class:

public class AdviceBindingTestAspect {

  public void oneIntArg(int age) {
     // whatever we like here, using "age" as needed
  }

}

The combination of the class declaration and XML definitions has the same effect as the following AspectJ aspect declaration:

public aspect AdviceBindingTestAspect {

  before(int age) : execution(* setAge(..)) && args(age) {
     // whatever we like here, using "age" as needed
  }

}

So let's turn our attention to the main subject of this article: how does the binding support for typed advice work and how can you use it?

Determining argument names and types

Look at the AspectJ aspect definition I gave you above for a moment. The advice declares a parameter, "age" of type int, and in the pointcut expression, "age" is bound by the "args" clause. The expression "args(age)" actually does two things: it restricts matching to join points where there is a single argument of type "int" (the type of "age"), and it binds the argument value to the "age" parameter.

In the Spring 2.0 version, we have exactly the same pointcut expression, but the method declaring the "age" parameter is defined elsewhere - in the AdviceBindingTestAspect class. Java reflection lets us down at this point. All we can determine is that the "oneIntArg" method takes a single parameter of type "int": we can't determine the parameter names. In this case since the advice method takes only one argument, and the pointcut binds only one argument, you could deduce that the int parameter must corresponding to "age", but when binding multiple arguments this may not always be possible. Matching argument names to argument types is critical to the matching process, and of course to passing arguments to the advice method itself.

Spring 2.0 resolves this issue by supporting a number of "ParameterNameDiscoverers". ParameterNameDiscoverer is a strategy interface, and multiple implementations are arranged in a ChainOfResponsibility. Spring attempts to discover argument names by applying the following strategies in turn:

1. If the argument names are explicitly specified, then the given argument names are used. Argument names can be specified in one of two ways:
   • They can be specified using the "arg-names" attribute of the <:aop:advice> element. In the example we've been working with so far, we could have specified arg-names="age" for example. The string value of this attribute takes a comma-delimited list of argument names.
   • If using the @AspectJ notation to define aspects, then the advice annotations (@Before, @AfterReturning, @AfterThrowing etc.) all support an optional "argNames" attribute. Again, this takes a comma-delimited list of argument names.
2. If argument names have not been explicitly specified, then we attempt to recover the argument names from the class file of the class defining the method. This is possible so long as the class was compiled with debug information (at a minimum, -g:vars). From the user perspective this is certainly the easiest and most natural way of obtaining argument names. Compiling with debug information makes it much easier to diagnose problems in running code (stack traces can include source file and line number information for example). If you are worried about overhead, then -g:vars will ensure that the class files contain the minimum amount of debug information (LocalVariableTables) that Spring needs for this mechanism to work. What are the downsides of -g:vars? Your class files will be very slightly larger (this will not be an issue in the vast majority of cases), certain optimisations that the compiler would otherwise make (pertaining to the removal of unused local variables for example) will not be made, and reverse engineering of your application is slightly easier. If you are worried about the sound of lost optimisations, run some performance tests - you may well find the effect is not noticeable.
3. If local variable table information is not available for the method, then Spring tries to deduce the argument names from the pointcut expression and the signature of the method. Consider a method that takes 2 parameters, one of a reference type, and one of a primitive type. Given a pointcut expression that binds one variable using "this()" and one variable using "args()" we know that the primitive argument must be the one bound by args, because "this" must be a reference type. In the AspectJ pointcut language all of the binding pointcut designators have two forms: one that takes a type name, and one that takes a variable name. For example, I can write "this(Float)" which simply matches any join point where "this" is an instance of Float, or I can write "this(f)" which matches any join point where "this" is an instance of the type of "f", and binds the value to the "f" argument. To find out what the variables in the pointcut expression are, Spring uses the simple assumption that any string inside a binding pointcut expression that is a valid Java identifier name and starts with a lower case letter is a variable, and anything else is a type.

Using typed advice

Let's look at some of the features available.

Information about the current join point

Firstly, if any advice method has a first argument of type org.aspectj.lang.JoinPoint then a JoinPoint instance representing the current join point will be passed to the advice method. This provides equivalent functionality to the use of 'thisJoinPoint' within AspectJ advice. The JoinPoint object can be useful when writing generic advice that applies across a wide range of join points since it can give you reflective information about the join point, such as the method being executed under the join point. For around advice, you must use the type org.aspectj.lang.ProceedingJoinPoint instead of JoinPoint - this subtype of JoinPoint provides the critical "proceed" method that you must call when you wish to proceed with the computation under the join point.

As an alternative to JoinPoint, a first parameter of type org.aspectj.lang.JoinPoint.StaticPart will be passed an instance of JoinPoint.StaticPart instead of JoinPoint. This provides only statically available information about the join point (method and signature for example) but not the arguments and target object for the invocation being advised. Use of JoinPoint.StaticPart instead of JoinPoint may allow optimisations inside the AOP framework in the future. For now it is no more efficient than JoinPoint when using Spring AOP.

Here's a simple example using JoinPoint from the test suite;

XML fragment for advice definition

  <aop:advice
    kind="afterReturning"
    method="needsJoinPoint"
    pointcut="execution(* getAge())"
  />

Advice method declaration:

public void needsJoinPoint(JoinPoint tjp) {
   this.collaborator.needsJoinPoint(tjp.getSignature().getName());
}

And the test case that verifies a suitable JoinPoint object is passed to the advice method:

public void testNeedsJoinPoint() {
    mockCollaborator.needsJoinPoint("getAge");
    mockControl.replay();
    testBean.getAge();
    mockControl.verify();
}

(I'll write more about the approach to testing aspects I've taken here in a separate post....)

Method execution arguments

You've already seen an example of using "args" to bind the arguments at the method execution join point (remember than Spring AOP only supports method execution join points). You can read up on "args" (and all of the other AspectJ pointcut designators" in the AspectJ programming guide at the AspectJ website. "args" restricts matching only to the execution join points for methods that have a corresponding number of arguments, and can bind one or more of those arguments.

Here are some very simple examples:

args()

matches the execution of methods that take no arguments (so clearly there is nothing to bind here

args(..)

matches the execution of methods that take zero or more arguments (but still performs no binding)

args(x,..)

matches methods with one or more parameters, that have a first parameter of the type of "x", and bind the argument value to "x"

args(x,*,*,s,..)

a more contrived example. Matches the execution of methods that take at least 4 parameters. The first parameter must be of the type of "x", and the argument value will be bound to "x". The second and third parameters may be anything, but the fourth parameter must be of the type of "s" and the argument value will be bound to "s".

By combining named arguments, "*" (which matches a single argument of any type), and ".." (which matches zero or more arguments of any type) you can expose exactly the context information you need to the advice that executes at the join point.

Method return values

If your advice needs access to the return value of a method execution join point you can use afterReturning advice and bind the returned value using the "returning" attribute.

Here's a simple example:

<aop:advice
  kind="afterReturning"
  method="afterGettingName"
  returning="name"
  pointcut="execution(* getName())"
/>

Couple this with the method definition

public void afterGettingName(String name) {
   // advice body
}

and "afterGettingName" will be invoked on every successful return from an invocation of "getName" with the return value passed in as the parameter 'name'.

Note that the "returning" clause is doing two things here: it is restricting matching to only those method execution join points that return an instanceof String (the type of 'name'), and it is binding the return value to the parameter name.

If you use the returning attribute with a type name (rather than a variable name) it restricts matching to only those join points where the return value is an instance of the given type (but does not pass the actual return value to the advice).

Thrown exceptions

afterThrowing advice runs when an advised join point exits by throwing an exception. Often it's useful to have access to the actual exception that was thrown in the advice. You can use the "throwing" attribute to do this.

Consider the following aspect definition:

<aop:aspect id="legacyDaoExceptionTranslator" ref="exceptionTranslator">
  <aop:pointcut name="legacyDaoMethodExecution"
                   expression="execution(* org.xzy.dao..*.*(..))"/>
  <aop:advice 
     kind="afterThrowing"
     method="translateException"
     pointcut-ref="legacyDaoMethodExecution"
     throwing="hibEx"
  />
</aop:aspect>

and the accompanying method definition

  public void translateException(HibernateException hibEx) {
    throw SessionFactoryUtils.convertHibernateAccessException(hibEx);
  }

The advice will run whenever a legacy DAO method (written without Spring ;) ) throws a HibernateException, passing the thrown exception to the advice method where it can be converted to a Spring DataAccessException and rethrown.

(yes, that is all the code you need :) )

The executing instance

Consider the execution of a method that would result from a call to "testBean.getAge()". What if my advice needs access to the testBean instance on which the method executes? The pointcut designators "this" and "target" provide access to this instance. In AspectJ, both this and target are bound to the executing instance at the join point. In Spring AOP an advised object will be proxied. Using the "this" pointcut designator will bind the proxy object (the value of "this" for the object instance that represents the bean), and using the "target" pointcut designator will bind the true target.

For example:

<aop:advice
    kind="afterReturning"
    method="setAgeOnATestBean"
    pointcut="execution(* setAge(..)) and args(age) and this(bean)"
    arg-names="age,bean"
/>

This advice passes with the following test case:

public void testOneIntAndOneObjectArgs() {
 mockCollaborator.setAgeOnATestBean(5,testBean);
 mockControl.replay();
 testBean.setAge(5);
 mockControl.verify();
}

If we use "target" instead of "this": "execution(* setAge(..)) and args(age) and target(bean)" the test would fail. The mock collaborator would be expecting "testBean" (which will be an AOP proxy) to be passed as an argument, but because we used "target", the proxy target object will be passed instead. This is demonstrated by the following test case:

public void testTargetBinding() {
 Advised advisedObject = (Advised) testBean;
 TestBean target = (TestBean) advisedObject.getTargetSource().getTarget();
 mockCollaborator.setAgeOnATestBeanTarget(5,target);
 mockControl.replay();
 testBean.setAge(5);
 mockControl.verify();
}

Annotations

The AspectJ pointcut language provides rich support for matching and binding annotations. For Spring applications, the two most useful pointcut designators are probably "@annotation" and "@within".

"@annotation" matches when the subject of the join point has an annotation of the given type. For Spring, this means when the method being advised has an annotation of the given type. For example, the advice:

<aop:advice
    kind="before"
    method="beforeTxMethodExecution"
    pointcut="@annotation(tx)"
/>

when coupled with the signature of the "beforeTxMethodExecution" method (in order to determine the type of annotation that "tx" will match):

public void beforeTxMethodExecution(Transactional tx) {
  if (tx.readOnly()) { 
    ...
}

will match the execution of any bean method that has the "@Transactional" annotation. Remember that Spring is implicitly limited to execution join points only. The corresponding pointcut when using the full AspectJ language would be: "execution(* *(..)) && @annotation(tx)".

"@within" matches any join point within a type that has a given annotation. So to match execution of any bean methods within a type that has the "@Transactional" annotation we could write:

<aop:advice
    kind="before"
    method="beforeTxMethodExecution"
    pointcut="@within(tx)"
/>

The @AspectJ style

All of the examples I've shown you so far have used the XML schema form of aspect definition. Spring 2.0 can also make use of aspects written using the "@AspectJ style". It's out of scope for this blog entry to give a full tutorial on @AspectJ, but here's a quick example of how it works...

The first thing that you need to do is enable auto-proxying from @AspectJ aspects in your application context. This is trivial using the new schema support for AOP:

<aop:aspectj-autoproxy/>

Then if we define any beans in the application context that are actually @AspectJ aspects (annotated using the AspectJ annotations), Spring will automatically use those beans to configure AOP proxies. The transactional method execution example, written as an @AspectJ aspect, would look like this:

@Aspect
AnnotationDrivenTransactionManager {

  @Before("execution(* *(..)) && @annotation(tx)")
  public void beforeTxMethodExecution(Transactional tx) {
     // ...
  }

}

To use this aspect, we would simply add a definition such as the following to the configuration.

<bean class="...AnnotationDrivenTransactionManager" >

of course, all of the usual dependency injection capabilities are avaible for configuring the aspect.

One nice advantage of using this style of aspect definition, is that you can switch from using Spring AOP proxying to full AspectJ weaving simply by removing the "aspectj-autoproxy" element from your configuration, and compiling (or binary weaving) your application using AspectJ instead. If you are dependency injecting those aspects, then either their bean definitions have to be changed slighty to obtain the aspect instance for injection via an AtAspectJFactoryBean, or you could simply annotate the aspects as @Configurable and use the spring-aspects.jar aspect library.

• AspectJ - 7,400
• AJDT - 20,000

It's great to see the numbers looking so healthy, and interesting to note just how many folks are getting AspectJ through the integrated Eclipse tooling (AJDT).

Since the book was published, AJDT has introduced the Cross References View. If you are following along with the text, relationship information (such as "advises" and "advised by") is now shown in the Cross References View and not in the outline view. To run the junit tests for any project, simply select the testsrc folder in the package explorer and "run as... junit test" from the context menu. To run the main Simple Insurance application, select insurance.ui.SimpleInsuranceApp in the package explorer and "run as... SWT application" from the context menu. If you get an error about a missing dll, you're probably running it as a "Java application", and not as an "SWT application".

This version of the download includes all of the needed dependencies, bar MySQL which you will still need to download and install yourself to follow along with all of the Hibernate related examples.

Not wanting to name names, but I was using the woolwich cashpoint in southampton airport terminal building last night. I put my card into the machine, entered my pin, selected the amount of cash I wanted to withdraw.... whirr, whirr, whirr, clunk. Blank screen for several seconds, then the cash machine started rebooting! The boot sequence of a cash machine that has your card in it is not something you want to see. The thing that surprised me as the cash machine slowly came back into life is that is was running on.......... OS/2 Warp!!! There's an operating system I haven't seen in a long time. Making some educated guesses, that probably means the operator is a "blue" company, and that the back end was probably CICS running on Z/OS - which gives me some comfort as the 2PC probably worked and I won't be charged for the cash I never got (though I'm still going to check my statement ;)).

I never got my card back of course (the machine swallowed it for good - which if you think about it is all you can safely design it to do, since if the user has walked away in disgust in the interim period, spitting the card back out wouldn't exactly be safe). So I had to call my bank and cancel the card. It should take about 3 working days to get me a new one they reckon. So I have no card and no cash in the run-up to Christmas :(.

And yes, this is a true story, not just a ploy to get you to buy the round this Christmas!!

But I'm delighted to say that AspectJ 1.5.0 final has now shipped. You can get a copy of the command line compiler and tools from the AspectJ downloads page. You can also get AspectJ 5 integrated into the final releases of :

• AJDT 1.2 for Eclipse 3.0, and
• AJDT 1.3 for Eclipse 3.1

AspectJ 5 breaks new ground for the world of AOP in a number of areas including (afaik - please correct me if this is not the case):

• The first AOP language to fully support Java 5
• The first implementation of generic aspects (using type parameters in pointcuts, advice, and ITDs in addition to regular generics features)
• The first aspect language to provide a full reflection API (AjTypeSystem)
• The first aspect language to offer code-style, annotation-style (@AspectJ) and XML based configuration with the same weaver and semantics

Now that the code is finally released, I'm finally able to spend more time talking about some of the new features. Ron Bodkin highlighted one new "hidden nugget" in AspectJ 5 in his blog entry. Here's another one: What do you do the night before a release? Update the docs of course! So one of the things I spent Monday night doing was updating the popular AspectJ "quick reference" to include all of the AspectJ 5 features. Time to download the AspectJ 5 quick reference and update the copy on your wall. It is on your wall isn't it ;)

It's been a really busy last few weeks for me. Yesterday we finally made it to RC1 of AspectJ 5 (a release that has been a long time coming). This enabled AJDT to also put out RC1 releases for Eclipse 3.0 and 3.1. From a purely technical perspective, AspectJ 5 has been the hardest (and most technically interesting) thing that I've worked on in my career to date. It's a full update to the AspectJ language for Java 5 (but it also has lots of improvements over 1.2.1 for folks on JDK 1.4 or 1.3 as well). The edited highlights of the release include:

• Full generics support in pointcuts and inter-type declarations
• Generic aspects (this is a really cool language feature that opens up a lot of possibilities - I'll write more about this and the other features over the next few weeks). My favourite quote from Andy (Clement) on this one... "implementing generic aspects is rocket science" :)
• Full support for varargs, autoboxing, and covariance in pointcut expressions and join point matching
• A new aspect instantiation model, pertypewithin
• A whole new syntax, the "@AspectJ" annotation-based syntax for those stuck with tools that can't cope with the AspectJ keywords (are you reading Rob? ;) )
• Dramatically improved load-time weaving support
• A full reflection API, the AjTypeSystem - it's like the java.lang.reflect package but understands the AspectJ type system and can give details of pointcuts, advice, itds, and so on as well as methods and fields etc..
• A weaver tools API, that amongst other things, opens up the AspectJ pointcut parsing and matching engine for third-party integration. We exploit this to good effect in...

Spring 2.0 M1

Last week was The Spring Experience conference in Miami. What a great event and an amazing atmosphere - it really was something to be part of. We used the event to announce and release Spring 2.0 M1 (we also used the days right before the conference to finish 2.0 M1 - no trips to the beach for I21!). Spring 2.0 has significantly improved ease-of-use for AOP, and is much more powerful at the same time thanks to much closer integration with AspectJ.

The news of Spring 2.0 has spawned two of the most active threads on TSS in a long time:

• Why would anyone bother creating a J2EE application without using Spring these days??? (check out Rod's great post on who's using Spring?.)
• The anaemic domain model (A discussion centred around the ability that Spring 2.0 to dependency inject domain objects, the implementation of which uses an AspectJ aspect shipped in spring-aspects.jar)

Here's a summary of the Spring 2.0 AOP enhancements - there's much more to write about all this soon...

Spring AOP as a framework is not growing beyond its original boundaries. Instead we've simplified the configuration and enabled the use of the AspectJ pointcut language and even @AspectJ aspects. Instead of replacing Spring AOP with AspectJ, or growing the capabilities of Spring AOP beyond its current bounds, we believe in providing a seamless roadmap from using the out-of-the-box Spring aspects (such as the transaction management support), thru writing your own Spring aspects and advisors, and onto AspectJ aspects, without any jarring discontinuities. Thus you can use as little or as much of the capabilities as you need, and as your requirements change there will be a solution available to support you.

As of October, this relationship will move onto a new level as I have resigned from my current post at IBM to take up the post of Chief Scientist at Interface21. I will continue to work on and lead the AspectJ project (no change there), and will also be working on some of the Spring core and AOP support to make the integration with AspectJ as seamless as possible and to take the AOP message to as broad an audience as we can. I'm leaving behind a fantastic IBM team who have worked with me on AspectJ and AJDT these past few years, and they will carry right on working on these projects when I leave. Rest assured that I'm still working flat out on completing AspectJ 5 too.

I've written before about the combination of dependency injection, aspects, and annotations as forming the ideal platform on which to build applications (see " The New Holy Trinity" ). Spring and AspectJ are the two leading technologies in this space, and bringing them together under one roof promises to be very exciting. I'm sure that AspectJ can learn some things from the Spring community, but also that as an AspectJ community we have much to offer to Spring as well.

Thank you for the great support that you all give to the AspectJ project - it really does make a difference. I'm looking forward to delivering the tools you need to develop great software for a long time to come yet...

Regards, Adrian. AspectJ project lead.

I love it when a plan comes together ;)