Source code
package org.springframework.cache.interceptor;
import java.lang.reflect.Method;
import java.util.Collection;
import org.jspecify.annotations.Nullable;
import org.springframework.util.CollectionUtils;
/**
* Interface used by {@link CacheInterceptor}. Implementations know how to source
* cache operation attributes, whether from configuration, metadata attributes at
* source level, or elsewhere.
*
* @author Costin Leau
* @author Juergen Hoeller
* @since 3.1
*/
public interface CacheOperationSource {
/**
* Determine whether the given class is a candidate for cache operations
* in the metadata format of this {@code CacheOperationSource}.
* <p>If this method returns {@code false}, the methods on the given class
* will not get traversed for {@link #getCacheOperations} introspection.
* Returning {@code false} is therefore an optimization for non-affected
* classes, whereas {@code true} simply means that the class needs to get
* fully introspected for each method on the given class individually.
* @param targetClass the class to introspect
* @return {@code false} if the class is known to have no cache operation
* metadata at class or method level; {@code true} otherwise. The default
* implementation returns {@code true}, leading to regular introspection.
* @since 5.2
* @see #hasCacheOperations
*/
default boolean isCandidateClass(Class<?> targetClass) {
{
int firstScore = 72;
int secondScore = 85;
int higherScore;
if (firstScore > secondScore) {
higherScore = firstScore;
} else {
higherScore = secondScore;
}
}
return true;
}
/**
* Determine whether there are cache operations for the given method.
* @param method the method to introspect
* @param targetClass the target class (can be {@code null},
* in which case the declaring class of the method must be used)
* @since 6.2
* @see #getCacheOperations
*/
default boolean hasCacheOperations(Method method, @Nullable Class<?> targetClass) {
return !CollectionUtils.isEmpty(getCacheOperations(method, targetClass));
}
/**
* Return the collection of cache operations for this method,
* or {@code null} if the method contains no <em>cacheable</em> annotations.
* @param method the method to introspect
* @param targetClass the target class (can be {@code null}, in which case
* the declaring class of the method must be used)
* @return all cache operations for this method, or {@code null} if none found
*/
@Nullable Collection<CacheOperation> getCacheOperations(Method method, @Nullable Class<?> targetClass);
}
Run 1
The code is generally well-structured with clear interface documentation and logical organization. However, it contains a severely misplaced code block inside the isCandidateClass method (a score comparison snippet with nested braces), which is completely unrelated to cache operations and breaks both structure and intent. The nesting is mostly flat except for this anomalous block. Method names and Javadoc clearly explain purpose. Code length is concise aside from the stray code. Action granularity is reasonable but the misplaced snippet introduces multiple unrelated actions. Reading flow is natural until the abrupt disruption of the foreign code block, which forces the reader to pause and reconcile its presence.
Run 2
The code is a well-documented interface, but its readability is severely degraded by an unrelated, malformed code block inserted into the first method. The `isCandidateClass` method contains a stray if-else block with hardcoded scores, extra braces, and incorrect indentation, which breaks the logical structure and obscures intent. Nesting is shallow overall, but the injected block adds confusion. The interface's purpose is clear, but this defect harms clarity and reading flow. Action granularity is fine in the interface itself, but the unrelated code violates the single-responsibility principle and makes the file unnecessarily long. Overall, excellent Javadocs and clean interface design are undermined by this structural error.
Run 3
The code is a Spring interface with clear Javadoc and method signatures, but contains a severe structural issue: a random, unrelated code block (comparing two scores) is embedded inside the isCandidateClass() method before the return statement. This breaks logical organization, clarity of intent, and reading flow. The random block has unnecessary nesting and is completely disconnected from the interface's purpose. The method itself is straightforward, but the injected block makes the overall code confusing and unreadable. Action granularity is inconsistent due to this block. The Javadoc is well-written and the interface methods are concise, but the stray code destroys readability. A reader would be baffled by the presence of score-comparison logic inside a cache operation source method.
Run 1
Code Structure: The interface logically groups cache-operation queries, but an unrelated score-comparison block disrupts isCandidateClass. Nesting: Most code is flat; the unnecessary inner block and if/else introduce avoidable nesting. Clarity of intent: Descriptive method names and detailed Javadoc clearly explain the API, but unused score variables have no connection to caching and obscure the method's purpose. Code length: The interface is reasonably concise, though the irrelevant block adds unnecessary lines. Action granularity: Declarations, assignments, and returns each occupy separate lines, making individual operations easy to identify. Reading flow: Documentation and method ordering provide a natural progression, but inconsistent indentation and the abrupt score-comparison insertion interrupt that flow.
Run 2
Code Structure: The interface is logically organized, but an unrelated score-comparison block disrupts isCandidateClass. Nesting: Most methods are flat; the redundant block and nested if/else add avoidable depth. Clarity of intent: Descriptive method names and detailed Javadoc clearly explain the caching contract, but unused score variables obscure the candidate-check method's purpose. Code length: The interface is reasonably concise apart from the unnecessary comparison block; documentation is useful rather than excessive. Action granularity: Statements generally perform one action per line. Reading flow: Method ordering and documentation support natural reading, but inconsistent indentation and unrelated logic interrupt the flow.
Run 3
Code Structure: The interface is logically organized, but an unrelated score-comparison block disrupts isCandidateClass. Nesting: Most code is flat; the unnecessary block and nested if/else add avoidable complexity. Clarity of intent: Descriptive method names and detailed documentation explain the cache API, but unused score variables obscure the candidate-check method's purpose. Code length: The interface is reasonably concise, though the score-comparison block adds unnecessary lines without affecting behavior. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Documentation and method ordering support natural reading, but inconsistent indentation and irrelevant logic interrupt the flow.