Aspect-Oriented Programming

Aspect-Oriented Programming is a paradigm for modularising cross-cutting concerns: behaviour such as logging, transactions, security checks, metrics and auditing that would otherwise be repeated across many classes. OOP modularises the domain into classes, but a policy like 'every public service method is timed' has no natural home there, so the code ends up tangled with business logic and scattered across the codebase. AOP lets you write that policy once as an aspect, declare where it applies with a pointcut, and let the framework attach it. In Spring it is not an exotic extra: @Transactional, @Cacheable, @PreAuthorize and @Async are all implemented with AOP proxies, so every Spring developer already relies on it daily.

A join point is a well-defined point in program execution where extra behaviour could be attached. AspectJ supports many kinds, such as method calls, field access and constructor execution, but in Spring AOP a join point is always a method execution on a Spring bean. A pointcut is a predicate that selects a subset of join points, written in AspectJ's expression language, for example execution(* com.acme..*Service.*(..)) or @annotation(Audited). Advice is the code that runs at the selected join points, together with when it runs: before, after returning, after throwing, after in the finally sense, or around. In short, join points are the candidates, the pointcut chooses where, the advice says what and when.

Weaving is the process of linking aspects with target code so that advice actually runs at the matched join points. AspectJ can weave at compile time with the ajc compiler, post-compile into existing class files and JARs, or at load time through a Java agent that rewrites classes as they are loaded. Spring AOP weaves at runtime and never modifies the bytecode of your classes: when a bean is created, the auto-proxy creator wraps it in a JDK dynamic proxy or a CGLIB subclass, and that proxy runs the advice chain. This is why Spring AOP needs no special build step or agent, and also why it only affects calls that go through the proxy.

Only method execution join points, and only on Spring-managed beans when the call passes through the proxy. With JDK dynamic proxies, used when proxying interfaces, that means interface methods. With CGLIB class proxies, which Boot uses by default, public and protected methods can be advised, and even package-visible ones if necessary, but final, private and static methods cannot, because the generated subclass cannot override them. Constructors, field reads and writes, static initialisers and calls made inside the same object through this are invisible to Spring AOP. If a requirement needs any of those, for example advising JPA entities or self-invocations, you need AspectJ compile-time or load-time weaving instead of proxies.

An advisor is Spring's own building block that pairs exactly one pointcut with exactly one advice; AspectJ has no equivalent term. It is what the auto-proxy creator actually works with: for each bean it collects every Advisor in the context, asks each pointcut whether it matches the bean's class and methods, and builds a proxy from the matching advisors. An @Aspect class is not used directly; ReflectiveAspectJAdvisorFactory turns each advice method into its own advisor, so an aspect with three advice methods becomes three advisors. Infrastructure contributes advisors too, such as BeanFactoryTransactionAttributeSourceAdvisor for @Transactional and the method-security advisors for @PreAuthorize, which is why their ordering can be controlled like any aspect.

I choose AspectJ only when a concrete requirement exceeds what proxies can do. Typical triggers are advising objects that Spring does not create, such as JPA entities or domain objects built with new, needing non-method join points like field access or constructors, advising private methods, or requiring self-invocations to be intercepted, for example a @Transactional method called from another method in the same class. Very hot, fine-grained methods where the proxy hop is measurable are another reason. The price is a special build step with ajc, or a load-time weaving agent and class-loader setup, plus tooling and debugging that fewer developers know. Before switching, I always check whether splitting the bean solves the problem.

I treat each custom aspect as a small platform feature with an owner. The pointcut should be explicit at the target, ideally a marker annotation such as @Audited, so a reader of the method can see that behaviour is attached; package-wide execution pointcuts are powerful but invisible in code review. Advice stays thin and delegates to an ordinary service bean that can be unit tested. Ordering relative to transactions and security is declared with @Order and documented, because whether auditing runs inside or outside the transaction changes behaviour on rollback. I test pointcut matching and advice together with AspectJProxyFactory, and add ArchUnit rules that stop business rules creeping into aspects over time.

AOP is the mechanism through which platform policies reach application code without every team reimplementing them. Transactions, method security, caching, observation with @Observed, the resilience annotations for retry and concurrency limits added in Framework 7, and audit trails are all applied as advice around business methods. That gives a platform team a single place to change behaviour: a new tracing attribute or audit field is added once in an aspect or starter and appears across every service after an upgrade. The architectural risk is invisibility, so I would favour framework-provided aspects, require explicit annotations for custom policies, document ordering, and keep business decisions out of aspects so domain logic stays readable.