InfoQ Article: The Annotation Hammer

I am very surprised that current versions of the Spring 2.0 docs are emphasizing the use of annotations to define aspects, rather than XML configuration.

From the docs: Spring's support for @AspectJ aspects is the recommended approach for declaring aspects for use with the Spring AOP framework. "@AspectJ" refers to a style of declaring aspects as regular Java classes annotated with Java 5 annotations.

Aspects are the sort of thing where you are going to want an application-wide view of how they are cross-cutting your application. Without explicit AspectJ tooling support, you are not going to get that if you use annotations.

What's worse is that pointcuts are not very refactoring-friendly. Being able to assess all of your application's pointcuts in a single XML file is a good way to head off errors introduced by refactoring. Hunting down all of your pointcut annotations in individual class files is not a scalable process.

AOP != Configuration != Meta-data!
It is time for developers to start seeing aspects as first class citizens of the application. You have classes to model concepts and you have aspects to model requirements (architecture requirements, domain requirements, or application requirements). The @AspectJ annotations is not there to configure the aspects, but to define them. I agree that it would probably be best if we could all use AspectJ traditional aspect constructs in our applications, but unfortunately not many tools support it at the moment (e.g. IntelliJ). @AspectJ annotation opens the window for us (IntelliJ users) to leverage AOP support in our applications by using this extremely powerful tool.

@AspectJ annotation opens the window for us (IntelliJ users) to leverage AOP support in our applications by using this extremely powerful tool.

I'm not following you. I'm an IntelliJ user, and I found it a pain in the ass to find all the classes that I had set up with @Aspect, and to track down their associated Pointcuts so I can see who is advising what.

How do you track down classes in the application? or functionality in general? You probably use proper naming strategies/conventions, and well packaging.

I've been playing with @Configurable annotation from Spring 2.0 and it looks very nice. When I showed it to my mates, they felt really confused how it all happened :) I run sample application in JBoss AS with runtime weaving and it worked quite well. In general I'm big fun of annotations and I'm happy that Spring guys've started to use them.

What I miss is inheritance of annotations. I hope I was be able to define one generic annotation and then create a bunch of specialised ones with additional attributes. The problem is when you try to write generic code to explore them. Without annotation inheritance it's hard to do it well.

I don't know the reasons why inheritance is not part of the annotation spec, but I know for sure that it was one of the most discussed things in the JSR group (unfortunately, I don't think these debates can be found somewhere so that we can understand the reasoning).

./alex
--
.w( the_mindstorm )p.

When annotations are discussed in the context of AOP/AspectJ, it could mean one of the two things.

1. Expressing aspect constructs
The traditional-style (also known as "code style") syntax extends the Java language using new keywords, and consequently requires a new compiler ('ajc'). The @AspectJ-style (also known as "annotation style"), on the other hand, extends the Java language using AspectJ-specific annotations instead of new keyword.

For example, here is a tracing aspect defined using the traditional style syntax.

public aspect TracingAspect {
	pointcut trace()
		: execution(* banking..*.*(..));
	
	before() : trace() {
		System.out.println("Entering " + thisJoinPointStaticPart);
	}
}

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class TracingAspect {
	@Pointcut("execution(* banking..*.*(..))")
	void trace() {}
	
	@Before("trace()")
	public void log(JoinPoint.StaticPart thisJoinPointStaticPart) {
		System.out.println("Entering " + thisJoinPointStaticPart);
	}
}

execution(@Secure * *(..))

The reason to prefer annotations over XML to express metadata is that with annotations it is much easier to write a pointcut to select the required join points.

Ah, here it is nice and pretty:

<aop:config>
  <aop:aspect id="tracingAspect" ref="tracingAspectBean">
    <aop:pointcut id="businessService" expression="execution(* banking..*.*(..))"/>
    <aop:before pointcut-ref="businessService" method="log"/>
  </aop:aspect>
</aop:config>

<aop:config>
  <aop:aspect id="tracingAspect" ref="tracingAspectBean">
    <aop:pointcut id="businessService" expression="execution(@Secure * *(..))"/>
    <aop:before pointcut-ref="businessService" method="log"/>
  </aop:aspect>
</aop:config>

Corby, you can sure argue with me :-). More importantly, we can sure learn a thing or two from each other.

Let me clarify a bit. When I said, "prefer annotations over XML to express metadata", I was referring to the use of annotations in "Selecting join points" part. The use of XML you are showing belongs to the "Expressing aspect constructs" part.

Tools (as you point), specific project needs, and personal preference direct the choice between traditional, @AspectJ, and XML-based syntax. There are a few fundamental differences between them, though:
1. The traditional syntax needs specific support from tools such as IDE. However, when you do have the right support, you can write concise code and express static crosscutting more directly. Of course, you also get visibility into crosscutting structure (see screenshots in this article, for example).
2. The @AspectJ syntax works reasonably well in environment without specific support for AspectJ (IntelliJ, for example), since such environments can treat the AspectJ code as Java code. It also works great in environments that support AspectJ. For example, in Eclipse you get all the goodies such as crosscutting reference view etc.
3. The XML syntax too works in environment without specific support for AspectJ. It also allows making certain changes to crosscutting functionality without having to recompile. However, a drawback will be (at least with current tools) the lack of visibility into crosscutting structure.

I use the traditional syntax if the team is using Eclipse as the IDE and AspectJ in the fundamental part of the project, @AspectJ in non-Eclipse environments, and XML if quick configuration changes is a requirement (performance monitoring, for example). It is also not uncommon to see use of multiple syntaxes in the same project.

Let me get back to the "prefer annotations over XML to express metadata" point. From AOP's perspective, it is easier to select the required join points when program elements themselves carry annotations instead of putting them in an associated XML file. For example,

@Entity
public class Customer implements Serializable {
    @Id Long id;
    ...

public class Customer implements Serializable {
    private Long id;
    ...

<hibernate>
    <class name="com.infoq.domain.Customer" table="customers">
        <id name="id" column="ID"/>
        ...

I use the traditional syntax if the team is using Eclipse as the IDE and AspectJ in the fundamental part of the project, @AspectJ in non-Eclipse environments, and XML if quick configuration changes is a requirement (performance monitoring, for example). It is also not uncommon to see use of multiple syntaxes in the same project.

I need to add one more point to already lengthy replies!

When we say XML-based syntax, it may mean one of the two things: The AspectJ way of defining concrete subaspects or the Spring way of defining typed advice. It may also mean using pointcut expression while defining proxy beans (but I will not discuss that, since it is quite simple to understand). Most of the generic discussion of XML-based syntax applies to all these styles.

The AspectJ way of defining subaspect targets the use cases that need changes to the selected join points without having to recompile. This is a purposefully limited syntax, where pretty much the only thing you can do is define subaspects and provide a definition for abstract pointcuts in the base aspects. You use aspects defined in this manner with the load-time weaver (although it is theoretically possible that compile-time and binary weaver will understand this syntax as well). Except for the style, there are no semantic differences between aspects defined using XML and using code. Here is an example of aspect defined using AspectJ's XML-based syntax.

<!-- META-INF/aop.xml -->
<aspectj>
  <aspects>
     <!-- Assume com.aspectivity.monitoring.JDBCMonitoringAspect 
             is an abstract aspect with an abstract monitoredOps() pointcut -->
     <concrete-aspect
          name="com.aspectivity.monitoring.JDBCMonitoringAspect"
          extends="com.aspectivity.monitoring.MonitoringAspect">
        <pointcut name="monitoredOps" 
                        expression="call(* java.sql.*.*(..))"/>
     </concrete-aspect>
     ...
  </aspects>
  ...
</aspectj>

        <pointcut name="monitoredOps" 
                  expression="call(* java.sql.*.*(..)) || execution(* banking..*.*(..))"/>

Thanks, Ramnivas, that's very helpful.