AspectJ distinguishes execution() from call() and offers get()/set()/initialization(). Which of these does Spring AOP actually implement, and why?

## AspectJ's pointcut designators (PCDs) AspectJ defines many **kinds** of join points, each selected by a pointcut designator: - **`execution(...)`** — the **execution** of a method/constructor body. Matched *inside* the callee. - **`call(...)`** — the **call site** of a method/constructor. Matched *inside the caller*, before dispatch. - **`get(...)` / `set(...)`** — reading / writing a **field**. - **`initialization(...)` / `preinitialization(...)`** — **constructor** execution join points. - **`staticinitialization(...)`** — a class's **static initializer** running. - **`handler(...)`** — an **exception handler** (catch block) executing. - **`adviceexecution()`** — execution of advice itself. ## What Spring AOP implements Spring AOP is **proxy-based**, purely a runtime construct. The proxy can observe exactly one thing: *its own method is being executed on the target bean*. Therefore Spring maps only to AspectJ's **`execution`** join point. Everything requiring visibility into other program points needs **bytecode weaving**, which Spring's proxies don't do: - **`call`** — would require instrumenting the *caller's* code. A proxy can't see the call site. (Note: under Spring, `execution` already covers the practical need, since interception is on the callee anyway.) - **`get`/`set`** — no field-access hook in a proxy. - **`initialization`/`preinitialization`** — the proxy is created *after* the target is constructed, so it can't wrap construction. - **`staticinitialization`, `handler`** — no proxy hook at all. If you write a Spring `@Aspect` pointcut using an unsupported primitive (e.g. `@Before("set(* *..*)")`), Spring's pointcut parser throws `org.springframework.aop.framework.AopConfigException` wrapping an **`UnsupportedPointcutPrimitiveException`** at context startup. ## Supported designators that *refine* method execution These work in Spring AOP because they merely **narrow** which method-execution join points match — they don't introduce new join-point kinds: - **`within(pkg..*)`** — join points within given types. - **`this(Type)`** — proxy is an instance of Type (matches the *proxy*). - **`target(Type)`** — target object is an instance of Type. - **`args(...)`** — argument types/values. - **`@annotation(Ann)`** — method carries annotation `Ann`. - **`@within` / `@target`** — the declaring/target *class* carries an annotation. - **`@args`** — argument runtime types carry an annotation. - **`bean(name)`** — Spring-specific: match by bean name/pattern. ## Subtlety: `this` vs `target` under proxies Because Spring interposes a proxy, `this()` refers to the **proxy object** and `target()` to the **underlying bean**. With a JDK proxy the proxy is *not* an instance of the concrete class (only its interfaces), which affects `this()` matching — a real senior-level nuance. ## Why this matters (the granularity gap) Proxy AOP's method-execution-only model is deliberately narrow: it keeps AOP a lightweight, no-build-step runtime feature that cleanly covers the dominant needs (transactions, security, caching, logging on inter-bean method calls). When you need finer granularity — trace every field mutation for auditing, intercept domain-object constructors, weave into non-Spring classes — you graduate to **full AspectJ**: compile-time weaving (`ajc`) or load-time weaving (`spring-instrument` agent + `@EnableLoadTimeWeaving`). AspectJ rewrites bytecode, unlocking every PCD above. ## When to use which - Default to Spring AOP; it's enough for annotation-driven concerns on bean method boundaries. - Move to AspectJ only for the non-method join points or to reach objects Spring doesn't manage — accepting the extra build/agent complexity.