Source code
package org.springframework.cache.interceptor;
import java.lang.reflect.Method;
import java.util.Arrays;
import org.jspecify.annotations.Nullable;
import org.springframework.core.KotlinDetector;
/**
* Simple key generator. Returns the parameter itself if a single non-null
* value is given, otherwise returns a {@link SimpleKey} of the parameters.
*
* <p>No collisions will occur with the keys generated by this class.
* The returned {@link SimpleKey} object can be safely used with a
* {@link org.springframework.cache.concurrent.ConcurrentMapCache}, however,
* might not be suitable for all {@link org.springframework.cache.Cache}
* implementations.
*
* @author Phillip Webb
* @author Juergen Hoeller
* @author Sebastien Deleuze
* @since 4.0
* @see SimpleKey
* @see org.springframework.cache.annotation.CachingConfigurer
*/
public class SimpleKeyGenerator implements KeyGenerator {
@Override
public Object generate(Object target, Method method, @Nullable Object... params) {
return generateKey((KotlinDetector.isSuspendingFunction(method) ?
Arrays.copyOf(params, params.length - 1) : params));
}
/**
* Generate a key based on the specified parameters.
*/
public static Object generateKey(@Nullable Object... params) {
if (params.length == 0) {
return SimpleKey.EMPTY;
}
if (params.length == 1) {
Object param = params[0];
if (param != null && !param.getClass().isArray()) {
return param;
}
}
return new SimpleKey(params);
}
}
Run 1
The code is highly readable with clear structure and intent. The class follows a logical organization, starting with imports, class documentation, and method implementation. Nesting is minimal—only two levels in generateKey—and the flat structure aids comprehension. The purpose of each block is evident: generateKey handles zero, single, and multiple parameter cases distinctly. Code length is concise with no redundant logic. Action granularity is well-maintained, with each line performing a single logical operation. The reading flow is natural, progressing from simple cases to the default. The only minor complexity is the Kotlin detection logic, which slightly obscures the intent of generate(), but the overall design remains clean and maintainable.
Run 2
The code is highly readable with clear structure and intent. The class is logically organized: a concise Javadoc explains purpose and limitations, followed by the interface implementation. The generate method handles Kotlin coroutine parameter extraction cleanly using a ternary, keeping the method flat. generateKey is well-structured with early returns for empty and single-parameter cases, avoiding deep nesting. Action granularity is appropriate—each conditional branch performs a distinct logical step. The code is concise but not cryptic, with clear variable names and minimal boilerplate. The only minor readability concern is the ternary operator in generate, which could be slightly clearer with an explanatory comment for non-Kotlin developers, but it does not significantly impair comprehension. Overall, the code follows strong readability principles: natural flow, flat nesting, single responsibility per line, and clear intent.
Run 3
The code is highly readable with a clear, logical structure and well-named class and methods. Nesting is minimal, with simple early returns in generateKey that keep the flow flat and easy to follow. Each condition and action is clearly separated, and the use of descriptive method and variable names clarifies intent. The single ternary expression in generate() is concise but still legible, and the handling of Kotlin suspending functions is briefly explained via the method name. The class Javadoc and method comments provide helpful context without being excessive. Code length is appropriate for the functionality, and reading flow is natural — from public API to helper method. Minor readability deduction is only due to the slightly dense ternary expression, but it does not significantly impair understanding.
Run 1
Code Structure: Clearly separates interface implementation from reusable key-generation logic. Nesting: Shallow, with early returns and only one nested conditional. Clarity of intent: Descriptive names and documentation explain the key-generation rules, though the Kotlin-specific parameter trimming lacks an explanatory comment, and the summary omits the array exception. Code length: Concise implementation with proportionate documentation. Action granularity: Most lines perform one action; the inline ternary combines detection, parameter copying, and delegation in one expression. Reading flow: Natural progression from adaptation to empty, single-value, and general cases; the wrapped ternary slightly interrupts an otherwise straightforward flow.
Run 2
Code Structure: Two focused methods cleanly separate Kotlin-specific parameter handling from key generation. Nesting: Early returns keep control flow mostly flat, with only one shallow nested condition. Clarity of intent: Descriptive names and documentation make the purpose clear, though removing the last parameter for suspending functions requires Kotlin knowledge, and the documentation does not mention the single-array exception. Code length: The implementation is concise without unnecessary logic. Action granularity: Statements generally perform one action each; the ternary expression combines detection, parameter copying, and delegation in a slightly dense line. Reading flow: The methods progress naturally from parameter normalization to empty, single-value, and composite-key cases. Minor formatting issues, including tightly packed imports and redundant parentheses around the ternary, slightly reduce readability.
Run 3
Code Structure: Responsibilities are logically separated between Kotlin-aware parameter handling and key generation. Nesting: Early returns keep control flow mostly flat, with only one small nested conditional. Clarity of intent: Descriptive names and documentation clearly explain key generation; the Kotlin-specific removal of the last parameter could benefit from a brief explanatory comment. Code length: The implementation is concise without unnecessary abstraction or repetition. Action granularity: Statements generally perform one action each, though the ternary expression combines parameter detection, adjustment, and delegation. Reading flow: The progression from empty parameters to a single eligible parameter and finally a composite key is natural. Minor formatting issues, including tightly grouped imports and redundant parentheses around the ternary, slightly reduce readability.