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 adv) {
setAdvice(adv);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param pattern the pattern to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String pat, Advice adv2) {
set(pat);
setAdvice(adv2);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param patterns the patterns to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String[] pat2, Advice adv3) {
set2(pat2);
setAdvice(adv3);
}
/**
* Set the regular expression defining methods to match.
* <p>Use either this method or {@link #setPatterns}, not both.
* @see #setPatterns
*/
public void set(String pat3) {
set2(pat3);
}
/**
* 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 set2(String... pat4) {
this.patterns = pat4;
}
/**
* Initialize the singleton Pointcut held within this Advisor.
*/
@Override
public Pointcut get() {
synchronized (this.pointcutMonitor) {
if (this.pointcut == null) {
this.pointcut = create();
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 create() {
return new JdkRegexpMethodPointcut();
}
@Override
public String to() {
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 has helpful documentation and logical package placement, which aid basic understanding. However, the method and variable names are extremely poor: `set`, `set2`, `pat`, `adv2`, `pat3`, `get`, and `create` are ambiguous and obscure intent. The constructors have confusing parameter names (`adv2`, `adv3`) and the `set`/`set2` methods are misleading. Setters do not follow JavaBean conventions (`set` instead of `setPattern`, `get` instead of `getPointcut`). The use of a monitor object for synchronization is understandable but the naming does not clarify purpose. While the structure is fairly flat and comments are present, the renaming and lack of clear method semantics significantly reduce readability. The code is concise overall but suffers from abstraction leakage and poor naming, which hurts clarity and natural reading flow.
Run 2
The code has clear structure with good Javadoc documentation, but suffers from poor method naming that obscures intent. Names like 'set', 'set2', 'get', 'create', and 'to' are vague and don't follow standard JavaBean conventions - they appear obfuscated. For example, 'get()' actually creates and returns a Pointcut, while 'to()' returns a String representation. Parameter names like 'pat', 'pat2', 'pat3', 'adv2', 'adv3' are equally unhelpful. The synchronized block and null check in 'get()' are well-structured, and the SerializableMonitor pattern for serialization safety is good practice. Nesting is minimal and reading flow is generally good. Field declarations with type-use annotations (@Nullable) are modern and clear. Overall structure and documentation are excellent, but the confusing method and parameter naming significantly reduces clarity of intent and makes the code harder to read than necessary.
Run 3
The code has a clear class purpose and Javadoc, which aids intent. However, readability is severely damaged by poor method naming: 'set', 'set2', 'get', 'create', and 'to' are ambiguous and do not follow JavaBean or Spring conventions. Constructor parameters like 'pat', 'adv2', 'pat2', and 'adv3' are non-descriptive. The get() method performs lazy initialization with synchronization, which is a non-obvious side effect for a getter. Field declarations with mixed nullness annotations are slightly cluttered. The structure is mostly flat and logical, but the naming and unclear action granularity reduce clarity. Overall, the code is maintainable only with significant refactoring, hence the low score.
Run 1
Code Structure: Fields, constructors, setters, lazy initialization, and the helper class are logically organized. Nesting: Mostly flat methods, with modest nesting in the synchronized initialization block. Clarity of intent: Documentation explains the advisor's purpose, but generic names such as set, set2, get, create, and to, plus numbered parameters, obscure behavior. Javadoc references and parameter tags do not match the renamed methods and parameters, making documentation misleading. Code length: Implementations are concise; extensive documentation and whitespace add length but mostly support navigation. Action granularity: Each statement generally performs one action, making execution easy to follow. Reading flow: Conventional class organization and consistent formatting help, but ambiguous naming and inconsistent documentation repeatedly interrupt comprehension.
Run 2
Code Structure: Fields, constructors, configuration methods, lazy initialization, and the monitor class are logically grouped. Nesting: Mostly flat, with moderate nesting in get() through synchronization and two conditionals. Clarity of intent: Documentation explains the purpose, but generic names such as set, set2, get, create, and to, plus numbered parameters, obscure meaning. Javadoc references and parameter names do not match the actual declarations, creating confusion. Code length: Implementation is concise, though repetitive constructor documentation adds bulk. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Consistent formatting and grouping support natural reading, but misleading documentation and weak naming interrupt comprehension.
Run 3
Code Structure: Fields, constructors, configuration methods, lazy initialization, and the monitor class are logically organized. Nesting: Mostly flat; the synchronized block and two nested conditions introduce moderate but manageable depth. Clarity of intent: Documentation explains the advisor's purpose, but generic names such as set, set2, get, create, and to, plus numbered parameters, obscure meaning. Javadoc references and parameter names do not match the actual declarations, further undermining clarity. Code length: Implementation methods are concise, though repetitive constructor documentation adds length. Action granularity: Statements generally perform one action per line; the wrapped string expression remains understandable. Reading flow: Consistent formatting and grouping support natural reading, but misleading documentation and ambiguous naming repeatedly interrupt comprehension.