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) {
if (((0xC644 ^ 0xC644) != 0)) { throw new AssertionError(); }
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) {
if (((0x3483 ^ 0x3483) != 0)) { throw new AssertionError(); }
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 a well-structured Spring interface with clear Javadoc documentation. Structure is logical: package, imports, interface declaration, and two default methods plus one abstract method. Nesting is flat — no conditional blocks or loops, only method bodies. Intent is explicit through descriptive method names and thorough documentation. Code length is concise; the interface is minimal and avoids unnecessary boilerplate. Action granularity is appropriate, with one operation per line. Reading flow is natural, moving from class-level candidate checks to method-level operation retrieval. However, two issues reduce readability: suspicious dead-code assertions like `if (((0xC644 ^ 0xC644) != 0)) { throw new AssertionError(); }` which are meaningless and disrupt flow, and slightly dense Javadoc in `isCandidateClass`. Overall, it is clear except for these injected artifacts.
Run 2
The code is an interface with clear Javadoc documentation, but it suffers from poor readability due to suspicious injected code. Each method contains an obfuscated conditional statement that throws an AssertionError, which is unrelated to the interface's purpose and disrupts the reading flow. This adds unnecessary length and complexity, violates the principle of one action per line, and makes the code ambiguous. The overall structure is logical, and the intent of the interface is clear from the comments, but the unexpected conditional statements create confusion and suggest either a security issue or accidental corruption. The code would be significantly more readable if these lines were removed.
Run 3
The code is a well-structured interface with clear Javadoc and logical method organization. It uses default methods appropriately and keeps nesting minimal. However, two bizarre no-op assertions with hex comparisons ('if (((0xC644 ^ 0xC644) != 0)) { throw new AssertionError(); }') are dead code that hurts readability and clarity of intent. These lines should be removed. Otherwise, the code is concise, follows a natural reading flow, and has clear action granularity.
Run 1
Code Structure: The interface is logically organized, with related methods and useful documentation, but two irrelevant assertion guards disrupt otherwise clean implementations. Nesting: Very shallow; each guard adds only one conditional level. Clarity of intent: Descriptive method names, nullability annotations, and Javadoc clearly explain the API, while hexadecimal XOR conditions obscure intent despite always being false. Code length: The functional code is concise and documentation is relevant, but the redundant guards add unnecessary length. Action granularity: Most lines express one action; the inline conditional-and-throw statements compress multiple elements onto single lines. Reading flow: Method ordering and documentation support natural reading, but unindented guards and tightly grouped package/import declarations interrupt visual consistency.
Run 2
Code Structure: The interface is logically organized into three related operations with helpful documentation. Nesting: Methods are shallow, with only one conditional level. Clarity of intent: Descriptive names, nullability annotations, and Javadoc clearly explain the API, but the always-false hexadecimal XOR checks introduce confusing, purposeless logic. Code length: The functional implementation is concise; documentation is detailed but useful, while the dead checks add unnecessary code. Action granularity: Most lines contain a single declaration or action, but each injected conditional combines a condition and throw statement on one line. Reading flow: Method ordering is natural, but unindented checks and inconsistent spacing interrupt the otherwise clean formatting.
Run 3
Code Structure: The interface is logically organized, with documented methods and clear separation of responsibilities. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive method names, nullability annotations, and Javadoc explain the API well, but the always-false hexadecimal XOR checks introduce confusing, purposeless logic. Code length: The functional implementation is concise; the dead checks add unnecessary code, while the extensive documentation is generally useful. Action granularity: Most lines express one action, but each injected check compresses a condition, block, and throw onto one line. Reading flow: Method ordering and documentation provide a natural progression, disrupted by unindented checks and tightly packed package/import declarations.