Source code
package org.springframework.aop.support;
import java.io.Serializable;
import org.aopalliance.aop.Advice;
import org.jspecify.annotations.Nullable;
import org.springframework.aop.Pointcut;
import org.springframework.util.ObjectUtils;
/**
* Convenient class for regexp method pointcuts that hold an Advice,
* making them an {@link org.springframework.aop.Advisor}.
*
* <p>Configure this class using the "pattern" and "patterns"
* pass-through properties. These are analogous to the pattern
* and patterns properties of {@link AbstractRegexpMethodPointcut}.
*
* <p>Can delegate to any {@link AbstractRegexpMethodPointcut} subclass.
* By default, {@link JdkRegexpMethodPointcut} will be used. To choose
* a specific one, override the {@link #createPointcut} method.
*
* @author Rod Johnson
* @author Juergen Hoeller
* @see #setPattern
* @see #setPatterns
* @see JdkRegexpMethodPointcut
*/
@SuppressWarnings("serial")
public class RegexpMethodPointcutAdvisor extends AbstractGenericPointcutAdvisor {
private String @Nullable [] patterns;
private @Nullable AbstractRegexpMethodPointcut pointcut;
private final Object pointcutMonitor = new SerializableMonitor();
/**
* Create an empty RegexpMethodPointcutAdvisor.
* @see #setPattern
* @see #setPatterns
* @see #setAdvice
*/
public RegexpMethodPointcutAdvisor() {
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* The pattern still needs to be specified afterwards.
* @param advice the advice to use
* @see #setPattern
* @see #setPatterns
*/
public RegexpMethodPointcutAdvisor(Advice advice) {
setAdvice(advice);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param pattern the pattern to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String pattern, Advice advice) {
setPattern(pattern);
setAdvice(advice);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param patterns the patterns to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String[] patterns, Advice advice) {
setPatterns(patterns);
setAdvice(advice);
}
/**
* Set the regular expression defining methods to match.
* <p>Use either this method or {@link #setPatterns}, not both.
* @see #setPatterns
*/
public void setPattern(String pattern) {
setPatterns(pattern);
}
/**
* Set the regular expressions defining methods to match.
* To be passed through to the pointcut implementation.
* <p>Matching will be the union of all these; if any of the
* patterns matches, the pointcut matches.
* @see AbstractRegexpMethodPointcut#setPatterns
*/
public void setPatterns(String... patterns) {
this.patterns = patterns;
}
/**
* Initialize the singleton Pointcut held within this Advisor.
*/
@Override
public Pointcut getPointcut() {
synchronized (this.pointcutMonitor) {
if (this.pointcut == null) {
this.pointcut = createPointcut();
if (this.patterns != null) {
this.pointcut.setPatterns(this.patterns);
}
}
return this.pointcut;
}
}
/**
* Create the actual pointcut: By default, a {@link JdkRegexpMethodPointcut}
* will be used.
* @return the Pointcut instance (never {@code null})
*/
protected AbstractRegexpMethodPointcut createPointcut() {
return new JdkRegexpMethodPointcut();
}
@Override
public String toString() {
return getClass().getName() + ": advice [" + getAdvice() +
"], pointcut patterns " + ObjectUtils.nullSafeToString(this.patterns);
}
/**
* Empty class used for a serializable monitor object.
*/
private static class SerializableMonitor implements Serializable {
}
}
Run 1
The code is highly readable due to its clear structure, consistent formatting, and comprehensive Javadoc documentation. It uses flat nesting with only one level of synchronization, and each method performs a single logical action. Constructors are concise and delegate appropriately. The class follows Spring conventions, with fields clearly named and annotated for nullability. The use of a dedicated monitor object for synchronization is a good practice. Minor deductions: the empty constructor adds slight length, and the toString method could be marginally clearer, but overall the code is well-organized and easy to understand.
Run 2
This code is highly readable. The structure is logical: class declaration, fields, constructors, then setters, core logic, and helper class. Javadoc comments clearly explain intent for each public member. Nesting is minimal—only a synchronized block with a single if-statement. Methods are concise and perform one primary action per line. The reading flow is natural, with related methods grouped together and clear naming conventions. Minor deductions stem from slightly verbose import/package overhead and the serializable monitor field which could be further documented, but overall maintainability is excellent.
Run 3
The code is well-structured and highly readable. It follows clear package/import ordering, uses Javadoc consistently, and organizes fields, constructors, and methods logically. Nesting is minimal—only a single synchronized block and a conditional check. Intent is explicit through descriptive method names and meaningful Javadoc. Class and method lengths are appropriate; no unnecessary verbosity. Each line generally performs one action, improving comprehension. Reading flow is natural: fields, constructors, setters, core logic, helper methods, and a small inner class. Minor deductions include the slight redundancy in constructor overloads and the null-check block within getPointcut(), which could be slightly more concise, but these do not meaningfully impact readability. Overall, the code is a strong example of maintainable Spring-style Java.
Run 1
Code Structure: Fields, constructors, configuration methods, pointcut initialization, and supporting class are logically organized. Nesting: Most methods are flat; getPointcut has moderate nesting from synchronization and two conditional checks, but remains easy to follow. Clarity of intent: Descriptive names and thorough Javadoc clearly explain configuration, delegation, and lazy initialization. However, the fact that pattern changes after initialization do not update the existing pointcut is not explicit. Code length: Implementation methods are concise, though repetitive constructor documentation increases overall length. Action granularity: Statements generally perform one action per line, with clean separation of initialization steps. Reading flow: Consistent formatting and conventional ordering support natural reading; the multiline toString expression and specialized nullable-array syntax introduce only minor friction.
Run 2
Code Structure: Logically organized into fields, constructors, configuration methods, pointcut initialization, and a helper class. Nesting: Mostly flat; getPointcut has moderate nesting from synchronization and two conditional checks, but remains easy to follow. Clarity of intent: Descriptive names and detailed Javadoc clearly explain configuration, lazy initialization, and extension points. Code length: Implementation is concise, although repeated constructor documentation and generous spacing increase overall length. Action granularity: Statements generally perform one action per line; the multiline toString expression is straightforward. Reading flow: Consistent formatting and conventional member ordering support natural reading. Minor friction comes from framework-specific types, unusual array annotation placement, and the need to understand lazy initialization to follow when patterns are applied.
Run 3
Code Structure: Fields, constructors, configuration methods, initialization, and helpers are logically grouped. Nesting: Most methods are flat; getPointcut has moderate nesting from synchronization and two conditional checks, but remains easy to follow. Clarity of intent: Descriptive names and useful Javadoc clearly explain regex configuration, lazy initialization, and the extension point. Code length: Implementation is concise, though repetitive constructor documentation and generous spacing increase its visual length. Action granularity: Statements generally perform one action per line; the wrapped toString expression is still readable. Reading flow: Consistent formatting and a natural progression from construction to configuration and use support smooth reading. Minor friction comes from the unusual nullable-array annotation syntax and the need to understand inherited advisor behavior.