skip to content

Why is bean() described as a Spring-AOP-only designator with no AspectJ equivalent, and what are the consequences?

level: seniorimportance: should knowfreq 40%

answer

  1. bean name = container-only concept
  2. AspectJ weaves bytecode, no container
  3. bean() = Spring extension to AspectJ expr language
  4. breaks under native AspectJ LTW/CTW
  5. portable subset: execution/within/@annotation

basics

~20 s

AspectJ weaves at the class/bytecode level and knows nothing about Spring bean names, so it has no bean() designator. bean() only works inside Spring's proxy-based AOP, where the container maps join points to named beans.

solid answer

~40 s

AspectJ is a general Java weaver: it selects join points from bytecode using type, method, and lexical information — it has no notion of a 'Spring bean name', because bean names exist only in a Spring ApplicationContext. So AspectJ provides no bean() designator. Spring AOP, being proxy-based and container-aware, can additionally offer bean(idOrNamePattern) to match by the container's bean id/name. The consequences: (1) bean() works only with Spring's proxy AOP, not with native AspectJ load-time or compile-time weaving; putting bean() in an aspect woven by the AspectJ weaver fails to parse/match. (2) It's a portability boundary — an aspect that must run under both Spring AOP and AspectJ can't rely on bean(). (3) For name-independent selection you fall back to type/annotation designators (within, @within, @annotation) that both engines understand.

go deeper

for a junior

Just know bean() is Spring-only.

for a middle

Know AspectJ doesn't know bean names, so no bean() there.

for a senior

Explain the two engines, portability boundary, and safe common designators.

for a principal

Reason about migration paths, weaving-mode implications, and designing portable aspect libraries.

## Two different AOP engines Spring supports two AOP models: 1. **Spring AOP** — proxy-based (JDK dynamic proxies or CGLIB). Aspects are applied at runtime by wrapping **Spring beans** in proxies. The container knows every bean's **name/id**. 2. **AspectJ** — a full-blown weaver operating on **bytecode** at compile time (CTW) or load time (LTW). It knows classes, methods, fields, and lexical structure — but it has **no knowledge of a Spring container** or bean names. ## Why AspectJ can't have bean() A 'bean name' is purely a **Spring container concept**: it's the key under which an object is registered in the `ApplicationContext`. When AspectJ weaves a class, there may be **no Spring context at all** (AspectJ works on plain objects, `new`-ed instances, etc.). There is nothing for `bean(...)` to resolve a name against. Hence the AspectJ pointcut language simply has **no such designator**. `bean()` is Spring's own extension to the AspectJ pointcut expression language, resolved by Spring's `AspectJExpressionPointcut` / the container, **not** by AspectJ's weaver. ## Consequences and gotchas - **Only works in proxy-based Spring AOP.** If you switch an aspect to be woven by native AspectJ (e.g. `@EnableLoadTimeWeaving` with the AspectJ weaver, or CTW via the AspectJ compiler), `bean(...)` is **not recognized** and the pointcut won't behave as intended. - **Portability boundary.** If an aspect is meant to be shared between Spring-AOP and AspectJ deployments, avoid `bean()`; use designators common to both (`execution`, `within`, `@within`, `@annotation`, `args`, `target`, `this`). - **Self-invocation still applies.** Because `bean()` runs in the proxy world, internal `this.method()` calls bypass the proxy and thus the advice — same limitation as all Spring proxy AOP, independent of `bean()`. - **Name-based, not type-based.** Since AspectJ-style designators are type/lexical, migrating a `bean(*Service)` rule to AspectJ means re-expressing intent as `within(..)` on a package/type pattern or an annotation — which may not select exactly the same set. ## When to lean on it anyway If you're firmly in **Spring proxy AOP** (the default), `bean()` is a first-class, supported tool and there's no reason to avoid it. The 'no AspectJ equivalent' caveat only bites when you plan to weave with AspectJ itself.

  • Which pointcut designators are safe to share between Spring AOP and native AspectJ?
    The standard AspectJ ones both understand: execution, within, @within, @annotation, @target, args, target, this, @args. bean() is NOT — it is Spring-only.
  • If you're using @EnableLoadTimeWeaving with real AspectJ, can you keep bean() rules?
    No — under native AspectJ weaving bean() isn't part of the pointcut language and won't match. You must re-express the selection with type/annotation designators.

saying these in an interview costs you the question

  • Claiming bean() also works in AspectJ compile-time/load-time weaving
  • Saying bean() matches on class name so it maps trivially to within()
  • Thinking bean() escapes the proxy self-invocation limitation

context

resolving links…