Some doubts related to the AOP configuration in Spring

Question

I am studying for Spring Core certification and I have a doubt related how Spring handle AOP.

Reading the documentation it seems to understand that exist 2 way to obtain AOP in Java:

Using AspectJ that using byte code modification for aspect weaving offers a full-blown Aspect Oriented Programming language. (so it seems to me that AspectJ is a differnt language that can be integrated with Java to offer it the AOP features).
Spring AOP: used in Spring framework that uses dynamic proxies for aspect weaving instead the bytecode modification.

So my doubts are mainly the followings:

1) Reading the documentations found the following method to add the AOP support to my Spring application:

USING JAVA CONFIGURATION CLASS:

@Configuration
@EnableAspectJAutoProxy
@ComponentScan(basePackages=“com.example”)
public class AspectConfig {
    ...
}

USING XML CONFIGURATION:

<beans>
    <aop:aspectj-autoproxy />
    <context:component-scan base-package=“com.example” />
</beans>

As you can see in both configurations there is a reference to AspectJ:

@EnableAspectJAutoProxy

and

<aop:aspectj-autoproxy />

Why? If Spring use Spring AOP instead AspectJ why there is a reference to AspectJ when I configure AOP in Spring?

2) In the previous examples are show 2 way to configure Spring: by Java configuration class and by XML configuration. I know that exist a third way to configure a Spring application: by the use of annotations. So exist a way to configure AOP using the annotations?

kriegaex kriegaex · Accepted Answer · 2014-12-06T17:58:36

I think that these Spring AOP settings with references to AspectJ in their names are indeed more irritating than helpful. I can understand why you are confused. Spring AOP is really a different concept from AspectJ. As you said: dynamic JDK or CGLIB proxies in Spring AOP versus byte code instrumentation during compile or load time in AspectJ. Other differences are:

AspectJ compile-time weaving needs a special compiler called Ajc. It is basically an Eclipse Java compiler Ecj enhanced by the aspect weaver which does the instrumentation. In contrast, Spring AOP creates dynamic proxies during runtime.
In AspectJ there are two syntax variants: native and annotation-based. The former is more elegant and expressive, a superset of Java and definitely needs Ajc to be compiled. The latter uses Java annotations and can be compiled with Javac, but needs the aspect weaver contained both in Ajc (compile time) and in the weaving agent aspectjweaver.jar (load time) to "finish" them and make them usable during runtime. Both variants need the AspectJ runtime contained in both aspectjrt.jar (very small, used for compile-time-woven aspects during runtime) and aspectjweaver.jar (much bigger, used for load-time weaving, contains both the runtime and the weaver).
AspectJ works for any Java class, it does not need or even know about the Spring framework. Spring AOP needs the Spring framework as a foundation, you can only instrument Spring Beans/Components with it, not Spring-agnostic POJOs.
AspectJ is more efficient because it avoids proxies. But Spring AOP is an optional part of the Spring framework anyway, so if you use Spring and method execution interception of Spring Beans is all you need, it makes perfect sense to use it.
Spring AOP uses a subset of the AspectJ pointcut syntax. Maybe this is the subtle reason why Spring AOP uses AspectJ references, but I still think it was a bad decision to not differentiate the two concepts from one another more clearly with regard to nomenclature. Besides, the common poinctut language subset is defined in a little JAR called aopalliance.jar because long ago a so-called "AOP Alliance" has defined that syntax. The dominating and by far most powerful AOP language today is AspectJ, though, so in reality AspectJ (maintained by Eclipse) is the leader in that area, IMO.
When I say that Spring AOP uses a subset of AspectJ syntax, conversely it means that AspectJ offers a superset. There are more pointcut types such as call(), set(), get() etc. and you have way more options to intercept joinpoints and apply cross-cutting concerns to your code base via advice or inter-type definition.

I do not understand your question #2. The configuration class in your example does use annotations, so there is no third way. ;-) But there is an old, really outdated AOP approach in Spring called interceptors. It is a leftover of an early AOP approach and kind of obsolete nowadays, even though it is still usable.

Both Spring AOP and AspectJ can be configured via XML or annotations within Spring. :-)

Some doubts related to the AOP configuration in Spring

2 Answers