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 has a clear purpose and basic logical organization, but readability is reduced by formatting and structure issues. The interface includes two default methods and one abstract method, but their layouts are inconsistent. The first default method is reasonably formatted, but the Javadoc for the second method is cramped and the method is collapsed onto one line, disrupting flow. The abstract method declaration is clear but could be separated with better spacing. Imports are compressed onto single lines, which is not ideal for scanning. Action granularity is mostly good, but the one-line method body hurts clarity. Nesting is not a major issue, but the inconsistent indentation and compressed Javadoc sections harm natural reading flow and clarity of intent. Overall, the code is functional but would benefit from consistent formatting and better separation of documentation and method signatures.
Run 2
The code is an interface with Javadoc, but readability is significantly hurt by formatting. Imports are collapsed onto one line, Javadoc is not separated from declarations, and method braces/annotations are placed erratically. For example, `default boolean hasCacheOperations` has its annotation and signature on the same line as the closing Javadoc. This breaks reading flow and makes the structure feel tangled. While the logic itself is simple and the intent is reasonably clear due to the Javadoc, the visual presentation obscures it. Action granularity is mostly one action per line inside method bodies, but the surrounding formatting negates that benefit. Overall, it reads like poorly auto-formatted code, requiring extra effort to parse.
Run 3
The code has clear purpose and reasonable documentation, but readability is undermined by inconsistent formatting and line breaks. The interface structure is logical, but methods and Javadocs are compressed onto single lines in places (e.g., 'default boolean isCandidateClass' and 'hasCacheOperations'), reducing readability. Reading flow is disrupted because some Javadocs start on the same line as method declarations. Action granularity is mixed, with some lines containing multiple logical actions, such as method declaration and return statement. Nesting is flat, which is good, but code length is unnecessarily dense due to formatting rather than actual logic. Overall, the content is understandable, but physical layout significantly lowers readability.
Run 1
Code Structure: The interface logically groups three related cache-introspection methods, but inconsistent formatting weakens visual organization. Nesting: Very shallow, with no nested control flow. Clarity of intent: Descriptive method names, nullable annotations, and detailed Javadoc clearly explain behavior and contracts. Code length: Implementation is concise; documentation is lengthy but mostly useful. Action granularity: Methods perform a single action, but multiple imports share lines, and declarations, returns, braces, and comment boundaries are sometimes compressed together. Reading flow: The method order is natural, progressing from class candidacy to operation checks and retrieval, but irregular line breaks and brace placement interrupt scanning.
Run 2
Code Structure: The interface logically groups three related cache-operation methods, but inconsistent placement of comments and braces weakens presentation. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive method names, nullable annotations, and thorough Javadoc clearly explain responsibilities and behavior. Code length: Implementations are concise; documentation is lengthy but useful for an API contract. Action granularity: Multiple imports share lines, and some method declarations, return statements, and closing braces are compressed together, reducing scanability. Reading flow: Method ordering is natural, moving from class candidacy to operation detection and retrieval, but irregular formatting interrupts otherwise straightforward reading.
Run 3
Code Structure: The interface logically groups related cache-operation methods, though inconsistent formatting weakens visual organization. Nesting: Minimal nesting and simple default implementations make the code easy to follow. Clarity of intent: Descriptive method names, nullability annotations, and detailed Javadocs clearly explain purpose and behavior. Code length: The implementation is concise; documentation is lengthy but mostly useful for defining the contract. Action granularity: Multiple imports share lines, and some declarations, return statements, and braces are compressed together, reducing scanability. Reading flow: Methods appear in a sensible order, but comments starting beside declarations and inconsistent brace placement interrupt otherwise natural reading.