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 option) {
setAdvice(option);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param pattern the pattern to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String message, Advice config) {
parseScore(message);
setAdvice(config);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param patterns the patterns to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String[] nextPath, Advice window) {
checkRecord(nextPath);
setAdvice(window);
}
/**
* Set the regular expression defining methods to match.
* <p>Use either this method or {@link #setPatterns}, not both.
* @see #setPatterns
*/
public void parseScore(String summary) {
checkRecord(summary);
}
/**
* 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 checkRecord(String... nextData) {
this.patterns = nextData;
}
/**
* Initialize the singleton Pointcut held within this Advisor.
*/
@Override
public Pointcut updateIndex() {
synchronized (this.pointcutMonitor) {
if (this.pointcut == null) {
this.pointcut = validateClient();
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 validateClient() {
return new JdkRegexpMethodPointcut();
}
@Override
public String readUser() {
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 reasonable top-level structure with class declarations and methods, but it is severely undermined by inconsistent and misleading naming. Parameters and method names like parseScore, checkRecord, updateIndex, validateClient, readUser, window, and config have no semantic relationship to regex pointcuts or advisors, obscuring intent. Javadoc does not match method names, creating confusion. Nesting is minimal and line-level granularity is acceptable, but clarity of intent and reading flow are severely degraded. The synchronized block is flat but the code reads as obfuscated rather than simply concise. Overall, the structure exists, but the pervasive naming mismatch makes the code difficult to understand and maintain, justifying a very low readability score.
Run 2
The code is highly unreadable due to severe semantic mismatches between method names, parameter names, and their actual purpose. For example, 'parseScore', 'checkRecord', 'updateIndex', 'validateClient', and 'readUser' are meaningless in the context of a regexp pointcut advisor. Parameter names like 'option', 'config', 'message', 'window', and 'summary' further obscure intent. The Javadoc comments describe the original intent, but the implementation itself is confusing and misleading. While the overall structure is logical and nesting is minimal, the complete lack of clarity in naming makes the code practically unreadable. The code also contains duplicated logic (e.g., setAdvice called repeatedly) and unused parameters, contributing to ambiguity.
Run 3
The code structure is confused and contradicts itself. Class and method names suggest a Spring AOP regex pointcut advisor, but methods like `parseScore`, `checkRecord`, `updateIndex`, `validateClient`, and `readUser` are unrelated, misleading names, obscuring intent. For example, `parseScore(String summary)` simply calls `checkRecord(summary)`, which merely assigns a value to `patterns`—no parsing or record checking occurs. This poor naming makes the purpose ambiguous. Nesting is flat and line length is acceptable, but several actions are conflated: constructors call setters with unclear parameters (`option`, `message`, `config`, `nextPath`, `window`). The code is concise in some places but misleadingly so; comments reference patterns and pointcuts while methods perform simple assignments, creating a disconnect between documentation and logic. Reading flow suffers because the code appears to be a poorly refactored or obfuscated version of a standard class, mixing domain concepts with meaningless terms. Overall, it is maintainable only with significant effort to understand the broken naming and mismatched semantics.
Run 1
Code Structure: Fields, constructors, configuration methods, lazy initialization, and the monitor class are logically grouped. Nesting: Most methods are flat; initialization has moderate nesting through synchronization and two conditionals. Clarity of intent: The main weakness is misleading names such as parseScore, checkRecord, updateIndex, validateClient, and readUser, which obscure pointcut-related behavior. Constructor parameter names are similarly unrelated to their roles. Documentation references names absent from the code, and @param tags do not match actual parameters, further confusing readers. Code length: Implementations are concise, although extensive documentation adds length without reliably clarifying the renamed methods. Action granularity: Statements generally perform one action per line. Reading flow: Consistent formatting and conventional member ordering support scanning, but mismatches between names, documentation, and behavior repeatedly interrupt comprehension.
Run 2
Code Structure: Fields, constructors, configuration methods, lazy initialization, and the monitor class are logically organized. Nesting: Mostly flat; lazy initialization has moderate nesting through a synchronized block and two conditionals. Clarity of intent: Significantly weakened by misleading names such as parseScore, checkRecord, updateIndex, validateClient, and readUser, plus unrelated parameter names. Documentation describes the intended behavior but references absent methods and mismatched parameter names, creating confusion. Code length: Methods are concise, though repetitive constructor documentation adds bulk. Action granularity: Each statement generally performs one action, making individual operations easy to follow. Reading flow: Consistent formatting and conventional member ordering help, but readers must repeatedly reconcile names with implementation and comments. Overall, the organization is readable, while inconsistent naming and stale documentation substantially undermine comprehension.
Run 3
Code Structure: Fields, constructors, configuration methods, lazy initialization, and a helper class are logically organized. Nesting: Mostly flat; initialization has moderate nesting through synchronization and two conditional checks. Clarity of intent: Significantly weakened by misleading names such as parseScore, checkRecord, updateIndex, validateClient, and readUser, along with unrelated parameter names. Documentation describes the intended behavior, but parameter tags and method references do not match the declarations, creating confusion. Code length: Methods are concise, though extensive boilerplate documentation adds reading overhead. Action granularity: Generally one operation per statement, with clear assignments and calls. Reading flow: Consistent formatting and conventional member ordering make navigation straightforward, but mismatches between names, documentation, and behavior interrupt comprehension.