What are limitations of using the default JDK dynamic proxies in Spring AOP?

Question

Options

• AIt cannot intercept constructor calls
• BMethod calls inside the same class cannot be intercepted.
• CThere are less available pointcut designators.
• DOnly public interface method calls can be intercepted
• EAll of the above

• A
  7% (3)
• B
  2% (1)
• C
  17% (7)
• D
  2% (1)
• E
  71% (29)

Explanation

All four options (A–D) describe genuine, well-documented limitations of JDK dynamic proxies in Spring AOP, making "All of the above" the only complete answer.

• A is a real limitation: Spring AOP is proxy-based and intercepts method invocations, not object instantiation - constructor calls are entirely invisible to the proxy.
• B is a real limitation: When a bean method calls another method on this, the call bypasses the proxy and hits the target object directly, so no advice fires - this is the infamous "self-invocation" problem.
• C is a real limitation: Spring AOP supports only a subset of AspectJ pointcut designators (e.g., no call, initialization, get, set, cflow), because it relies on runtime proxies rather than compile-time or load-time weaving.
• D is a real limitation: JDK dynamic proxies work by implementing the target's interfaces, so only public methods declared on those interfaces can be proxied - protected, package-private, or class-only methods are unreachable.

There are no wrong distractors here; A–D are all independently correct, and the trick the exam is testing is whether you know all four apply, not just one or two.

Memory tip: Think "CISD" - Constructors, Internal calls, Subset of designators, Declaration on interface - the four walls of the JDK proxy "cage." If your code hits any of these four walls, the proxy can't see it, and you need CGLIB or full AspectJ.

No community discussion yet for this question.