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 a) {
setAdvice(a);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param pattern the pattern to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String b, Advice c) {
a(b);
setAdvice(c);
}
/**
* Create a RegexpMethodPointcutAdvisor for the given advice.
* @param patterns the patterns to use
* @param advice the advice to use
*/
public RegexpMethodPointcutAdvisor(String[] d, Advice e) {
b(d);
setAdvice(e);
}
/**
* Set the regular expression defining methods to match.
* <p>Use either this method or {@link #setPatterns}, not both.
* @see #setPatterns
*/
public void a(String f) {
b(f);
}
/**
* 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 b(String... g) {
this.patterns = g;
}
/**
* Initialize the singleton Pointcut held within this Advisor.
*/
@Override
public Pointcut c() {
synchronized (this.pointcutMonitor) {
if (this.pointcut == null) {
this.pointcut = d();
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 d() {
return new JdkRegexpMethodPointcut();
}
@Override
public String e() {
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 a logical structure with clear sections for constructors, setters, and overridden methods, and the javadoc comments are thorough. However, readability is severely hindered by poorly named methods (a, b, c, d, e) and parameters (a, b, c, d, e, f, g). The nested synchronized block adds some complexity but is mitigated by only having one level of nesting. The intent of methods is obscured by these non-descriptive names despite the comments. The code is relatively concise but uses unconventional formatting. Each line generally contains one action, and the flow progresses logically, but the naming makes it read like obfuscated code. The class would score higher with proper method and parameter names, as the comments suggest these are setPattern, setPatterns, getPointcut, createPointcut, and toString methods.
Run 2
The code has severe readability problems primarily due to obfuscated method names (a, b, c, d, e) that completely obscure intent. What should be setPattern, setPatterns, getPointcut, createPointcut, and toString are replaced with meaningless single letters. Parameter names (a, b, c, d, e, f, g) follow the same anti-pattern. This forces readers to rely on comments to understand purpose. The structure itself is logical and nesting is minimal, but clarity of intent is critically damaged. Action granularity is mostly fine, with one action per line. Javadoc comments are comprehensive, which helps, but the contradiction between documentation and code identifiers creates cognitive friction. The synchronized block is straightforward, and the class organization follows Spring conventions. However, the naming alone drops readability dramatically—a reader cannot understand what any method does without reading documentation or implementation details.
Run 3
The code is virtually unreadable due to deliberate obfuscation of all method names (a, b, c, d, e), parameters (a, b, c, d, e, f, g), and fields. While the class-level Javadoc is intact, the method-level documentation now describes methods that no longer exist by name. The original intent is completely obscured, requiring external knowledge to determine what each method does. Although the overall structure and nesting are acceptable and inherited from the original Spring code, the arbitrary renaming destroys clarity of intent, action granularity, and natural reading flow. The 'score' of 0 reflects that the code is functionally illegible without extreme effort.
Run 1
Code Structure: Fields, constructors, configuration methods, lazy initialization, and a helper class are logically organized. Nesting: Mostly flat, although synchronized initialization contains two nested conditionals; this remains manageable. Clarity of intent: Descriptive class and field names and substantial documentation help, but single-letter method and parameter names obscure operations. Documentation references names such as setPattern and createPointcut that do not match the declared methods, further confusing navigation. Code length: Implementation methods are concise; comments and whitespace add length but generally provide useful context. Action granularity: Statements largely perform one action per line, with only a conventional multiline string expression. Reading flow: Consistent formatting and grouping support scanning, but calls such as a(b), b(d), and d() force readers to repeatedly consult definitions to understand behavior.
Run 2
Code Structure: Fields, constructors, configuration methods, lazy initialization, and the monitor class are logically organized. Nesting: Mostly shallow, though lazy initialization has three nested control blocks. Clarity of intent: Descriptive field names and explanatory comments help, but single-letter method and parameter names obscure purpose. Documentation references original names such as setPattern and createPointcut that do not match the declared methods, reducing trust and forcing readers to infer mappings. Code length: Implementation is concise; extensive documentation and whitespace add length but mostly aid navigation. Action granularity: Statements generally perform one action per line, with straightforward constructor delegation and assignments. Reading flow: Conventional class layout supports top-to-bottom reading, but opaque calls such as a(b), b(d), and d() interrupt comprehension and make readers repeatedly consult method bodies.
Run 3
Code Structure: Fields, constructors, configuration methods, lazy initialization, and the monitor class are logically grouped. Nesting: Mostly flat, with moderate nesting in the synchronized initialization block. Clarity of intent: Descriptive class and field names and explanatory comments help, but single-letter method and parameter names obscure purpose. Documentation references names such as setPattern, setPatterns, and createPointcut that do not match the declared methods, making navigation confusing. Code length: Implementations are concise; documentation adds useful context but some repetition. Action granularity: Statements generally perform one action per line, with no compressed multi-action statements. Reading flow: Consistent formatting and conventional ordering support scanning, but calls such as a(b), b(d), and d() force readers to consult definitions repeatedly. Overall, sound organization is substantially weakened by ambiguous naming and inconsistent documentation.