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() {
{int lI0O_90fd3623=0,lI0O_ea4c98fe=0;while(lI0O_ea4c98fe<2){lI0O_90fd3623^=(lI0O_ea4c98fe<<1)^0x5;lI0O_ea4c98fe++;}lI0O_90fd3623^=lI0O_90fd3623;}
}
/**
* 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 generally well-structured with clear Spring conventions, but contains a critical readability issue: an obfuscated no-op block in the empty constructor that severely disrupts clarity and appears to be unintentional or malicious. Beyond this, the class shows logical organization with clear method separation, moderate nesting (only one level in getPointcut()), and good use of Javadoc. Field declarations use type-use annotations properly but the `@Nullable` placement on arrays may reduce clarity. The synchronized block is clean with single responsibility per method. However, the mysterious while-loop with meaningless variable names (`lI0O_90fd3623`, `lI0O_ea4c98fe`) and bitwise operations in the constructor drags the score down significantly—it serves no apparent purpose and complicates understanding. The code length is reasonable and follows single-action-per-line principles. Without the obfuscated block, this would score 18-19; the presence of that code makes the intent ambiguous and breaks reading flow.
Run 2
While the code generally follows good structure and has clear intent, it is severely compromised by an obfuscated line in the no-argument constructor. The line '{int lI0O_90fd3623=0,lI0O_ea4c98fe=0;while(lI0O_ea4c98fe<2){lI0O_90fd3623^=(lI0O_ea4c98fe<<1)^0x5;lI0O_ea4c98fe++;}lI0O_90fd3623^=lI0O_90fd3623;}' is nonsensical and completely breaks readability. The remaining code demonstrates good practices: logical class structure, flat nesting, one action per line, and natural reading flow. However, the unnecessary complexity of the inserted line creates a tangled logic block, ambiguous purpose, and unnecessarily long code. The otherwise clear Java is unreadable at a critical point, making the overall code extremely difficult to understand. The score reflects this severe readability violation despite otherwise solid conventions.
Run 3
The code has a clear overall structure with proper Javadoc and conventional Spring patterns, but readability is severely compromised by an obfuscated block in the no-arg constructor. That while-loop with cryptic variable names (lI0O_90fd3623, lI0O_ea4c98fe) serves no apparent purpose and disrupts reading flow. Additionally, the class has mixed type annotation styles (`String @Nullable [] patterns`), minor nesting in getPointcut (synchronized block with if), and some constructor duplication. Intent is otherwise understandable, but the presence of dead/obfuscated code forces the reader to pause and question legitimacy. If that block were removed or replaced with a comment, the score would be significantly higher (around 16–17). As written, it violates clarity of intent and action granularity.
Run 1
Code Structure: Fields, constructors, configuration methods, and pointcut creation are logically organized, but the injected constructor block is unrelated clutter. Nesting: Mostly shallow; synchronized lazy initialization has moderate, understandable nesting, while the constructor adds an unnecessary block and loop. Clarity of intent: Descriptive names and Javadoc clearly explain the advisor, but cryptic constructor variables and pointless bitwise operations obscure intent locally. Code length: Functional methods are concise; documentation is useful, though the no-op constructor logic adds unnecessary length. Action granularity: Most statements perform one action per line, but the injected block compresses declarations, looping, and assignments onto a single line. Reading flow: Consistent formatting and method ordering support natural reading, interrupted sharply by the densely packed, poorly indented constructor code.
Run 2
Code Structure: Fields, constructors, configuration methods, and pointcut creation are logically organized, but the default constructor contains unrelated computation. Nesting: Generally shallow; synchronized lazy initialization has manageable nesting, while the constructor adds an unnecessary block and loop. Clarity of intent: Descriptive names and Javadoc explain the advisor well, but cryptic constructor variables and meaningless bitwise operations obscure intent. Code length: Most methods are concise; the constructor computation adds needless code. Action granularity: Most statements occupy separate lines, but the entire injected constructor block compresses declarations, iteration, and assignments onto one line. Reading flow: Conventional method ordering and documentation support natural reading, substantially disrupted by the unformatted, irrelevant constructor block.
Run 3
Code Structure: Fields, constructors, configuration methods, and pointcut creation are logically organized, but the empty constructor contains unrelated obfuscated computation. Nesting: Most methods are flat; synchronized lazy initialization has moderate, understandable nesting. Clarity of intent: Descriptive names and Javadoc explain the advisor well, while cryptic constructor variables and pointless bitwise operations obscure intent. Code length: Functional methods are concise, although the constructor's no-op loop adds unnecessary code. Action granularity: Most statements occupy separate lines, but the injected constructor block compresses declarations, a loop, and several assignments into one line. Reading flow: The class generally follows a natural progression with consistent formatting; the densely packed, unindented constructor block sharply interrupts that flow.