James Strachan likes the idea of using AOP to introduce annotations in your
code:

This will let us use our own conventions (naming conventions such as Java
Beans default conventions) and let AOP weave in all the annotations

Well, it’s not very often, but I strongly disagree with this.

Using pointcuts to specify where the annotations are going to be inserted
is a huge step backward that brings us back to XML hell.

The reason why we are moving away from XML as a metadata description language
is that it introduces redundancy:  in order to define where the metadata
is going to be introduced, you need to specify the Java element it applies to: 
class name or method name, parameter types, exceptions thrown, etc…  This
redundancy makes your code extremely fragile and even the most advanced IDE’s of
today don’t cover  the case of refactoring this kind of metadata.  If
you rename your method and forget to adjust your pointcut, you application will
break.  If you define your pointcut poorly, it might start introducing
annotations in unexpected parts of your application with similar disastrous
results.

JSR 175 annotations have two very strong points.  They are:

  • Close to your source code. 
  • Part of your Java type system.

These two points are already important separately, but taken together, they
take Java programming to a whole new level of expressiveness.

Besides, what is exactly the problem, James?  Are you afraid that the
Java syntax is becoming encumbered?  If so, then you need not worry: 
code folding and other IDE assistance will make it very easy for you to
completely ignore the annotations if you so desire.

In a similar vein, Rickard posted the following comment:

Yeah, the way we solved this (the annotation
nightmare) is to allow AOP pointcuts to introduce annotations. And then use
those annotations in pointcuts for aspects. E.g. instead of setting an
annotation "setter" on all set* methods and apply a "StoreToDb" aspect on those
methods, I can create a pointcut that says "apply attribute ‘setter’ on all set*
methods" and then have the "StoreToDb" trigger on the "setter" attribute. Just
as you mention, with this approach I only have to mark the special cases with
annotations; everything else is automatic. It works great, and is a big help.

I have to confess my skepticism about this approach as well.  It seems
to me that this method only adds a level of indirection for no obvious benefit. 
In effect, you are still defining a pointcut on "set*", calling it "StoreToDb"
and invoking an aspect on it.  Why the extra step?

All that being said, James original point is valid:  are we going to see
an abuse of annotations in the next couple of years?  Most likely. 
But I think it’s a little too early to worry about that right now.  As the
use of annotations percolates through our Java habits, good and bad practices
will emerge and we can rely on book authors and fellow bloggers to spot those as
they come.  And on Hani to keep these people in check.