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) {
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 highly readable. Structure is logical and interface methods are well-organized. Nesting is non-existent as it's an interface with flat default methods. Intent is crystal clear due to comprehensive Javadoc, good method naming, and clear use of @Nullable and @since annotations. Code length is concise—no unnecessary boilerplate. Action granularity is ideal: each default method has a single, clear action (returning a value or checking emptiness). Reading flow is natural, with methods ordered logically and documentation providing necessary context without redundancy. Minor deductions only because the extensive Javadoc, while beneficial, adds verbosity and the 'hasCacheOperations' method's inversion (checking emptiness) could be slightly more direct.
Run 2
The code is a well-structured Java interface with excellent readability. It clearly defines three methods, each with a specific purpose and Javadoc explaining intent, parameters, and return values. The structure is logical, with default methods followed by the abstract method. Nesting is non-existent. Clarity is high due to descriptive names like isCandidateClass and getCacheOperations, and annotations such as @Nullable improve intent. The code is concise—no redundancy or unused elements. Action granularity is appropriate, with each statement on its own line. Reading flow is natural, guiding the reader from class-level checks to method-level checks, then to retrieval of operations. Overall, it exemplifies clean, maintainable interface design.
Run 3
The code is a well-structured Java interface with clear intent. It follows standard Spring patterns, uses Javadocs extensively, and maintains flat nesting with one action per line. Method names and parameters are descriptive, and the default implementations are concise and readable. The reading flow is natural, moving from class-level candidate checks to method-level operation retrieval. Minor deductions: Javadocs are verbose for such a small interface, and the default `isCandidateClass` implementation returning `true` adds little value beyond documentation. Overall, highly readable.
Run 1
Code Structure: The interface is logically organized, progressing from class-level candidacy to method-level checks and operation retrieval. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit nullability annotations, and detailed Javadoc clearly communicate purpose and contracts. Code length: Implementation is minimal; documentation is somewhat verbose but explains important introspection behavior. Action granularity: Each executable line performs one clear action. Reading flow: Consistent formatting and related method ordering make the code easy to follow, although spacing between the package declaration and import groups would improve visual separation.
Run 2
Code Structure: A small, logically organized interface separates candidate detection, operation existence checks, and operation retrieval. Nesting: Default methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit nullability annotations, and thorough Javadoc make the contract clear. Code length: Executable code is concise; documentation is somewhat lengthy but explains important introspection behavior. Action granularity: Each default method performs one straightforward action, with no crowded statements. Reading flow: Methods progress naturally from class-level filtering to method-level checking and retrieval. Minor drawbacks are the lack of spacing between package/import groups and the long retrieval signature.
Run 3
Code Structure: A well-organized interface groups related cache-operation queries with clear contracts. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, nullability annotations, and thorough Javadoc make responsibilities and default behavior explicit. Code length: Executable code is concise; documentation is somewhat lengthy but explains important semantics. Action granularity: Each implementation contains a single return statement, and declarations remain clearly separated. Reading flow: The progression from class-level candidacy to method-level checks and operation retrieval is natural. Minor drawbacks are the lack of blank lines separating the package and import groups and the long final method declaration.