skip to content

What join points and targets can full AspectJ advise that proxy-based Spring AOP cannot?

level: middleimportance: should knowfreq 45%

answer

  1. Spring AOP: method execution on beans only
  2. AspectJ: call/execution/constructor/field/static/handler
  3. AspectJ hits any object, final, static, third-party
  4. call/get/set/cflow = AspectJ-only designators
  5. Subset of pointcuts in Spring

basics

~20 s

Spring AOP can only advise public method executions on Spring beans. Full AspectJ can additionally advise constructor calls, field reads/writes, static and private methods, final classes, and plain non-Spring objects — because it rewrites bytecode instead of wrapping a proxy.

solid answer

~40 s

Proxy-based Spring AOP supports exactly one join-point kind: **method execution** on a **Spring-managed bean**, and practically only public, non-final methods (CGLIB subclassing constraints). Full **AspectJ** weaves into bytecode, so it supports a much richer join-point model: method **call** and **execution**, **constructor** call/execution, **field get/set**, **static initializer** execution, **object (pre-)initialization**, exception **handler** execution, and **advice** execution — and it can target *any* object, including ones you `new` yourself, third-party library classes, `final` classes/methods, static methods, and private members. It also has pointcut designators Spring lacks (`call`, `get`, `set`, `withincode`, `cflow`). The cost is a weaving step (a special compiler or a load-time agent) instead of Spring AOP's zero-build proxying.

go deeper

for a junior

Knows Spring AOP is 'method-only'; may not enumerate AspectJ's extra join points.

for a middle

Lists the extra AspectJ join points (field, constructor, static, any object) and the pointcut-subset fact.

for a senior

Explains call-vs-execution and maps requirements to the weaving model needed.

for a principal

Weighs whether a genuine need for richer join points justifies the AspectJ build/agent cost across a codebase.

## The two models produce different reach ### Spring AOP (proxy) Because it works by putting a wrapper object in front of a **Spring bean**, it can only ever intercept **method execution** on that bean, and only when the call arrives through the proxy. Concretely it **cannot** advise: - Constructors (the proxy is created *after* construction). - Field reads/writes (a proxy has no way to intercept field access). - `static` methods (no instance to proxy). - `private` methods and, under CGLIB, `final` methods or `final` classes (can't subclass/override them). - Any object not created by the Spring container (things you `new`, JDK/library classes, entities). - Self-invoked internal calls (see the self-invocation pitfall). ### AspectJ (weaver) AspectJ modifies the **bytecode of the target itself**, so it operates on a full join-point model (from the AspectJ language): - **Method call** vs **method execution** (two distinct join points — call-site vs. callee-site). - **Constructor call / execution**. - **Field get / set** — e.g., audit every write to a field. - **Static initialization** of a type, and **object initialization / pre-initialization**. - **Exception handler execution** (`handler(SomeException)`). - **Advice execution**. And it can weave into **any** class — third-party jars, `final` classes, domain entities created with `new`, static utilities — none of which need to be Spring beans. ## Pointcut designators Spring AOP supports a **subset**: `execution`, `within`, `this`, `target`, `args`, `@annotation`, `@within`, `@target`, `@args`, `bean` (Spring-specific). AspectJ adds `call`, `get`, `set`, `withincode`, `cflow`, `cflowbelow`, `staticinitialization`, `handler`, `initialization`, `preinitialization`, and more. If you write one of those in a Spring AOP pointcut, it fails or is ignored — a common surprise. ## Practical implication If your requirement is 'advise a service method' — Spring AOP is plenty. If it is 'trace every write to this field', 'advise a domain object built with `new`', 'intercept a constructor', or 'weave a third-party final class' — only AspectJ can do it, and you accept its weaving step. ## Gotcha Using the `@Aspect` annotation with a `get()`/`set()` pointcut under Spring AOP does not silently upgrade you to AspectJ — Spring simply won't match those join points. The syntax is shared; the capability is not.

  • Give a concrete requirement that forces you off Spring AOP onto AspectJ.
    Auditing or logging every write to a specific field (a field-set join point), or advising a domain object created with new — neither is a bean method execution, so only AspectJ can weave it.
  • What is the difference between the 'call' and 'execution' join points?
    call matches at the caller's site (where the method is invoked from); execution matches at the callee's body. Spring AOP only supports execution; call is AspectJ-only.

saying these in an interview costs you the question

  • Claiming Spring AOP can advise fields or constructors with the right config
  • Thinking any @Aspect pointcut works identically under both
  • Believing Spring AOP can weave third-party/final classes
  • Not knowing call vs execution distinction

context

resolving links…