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 - 0x1) : params));
}
/**
* Generate a key based on the specified parameters.
*/
public static Object generateKey(@Nullable Object... params) {
if (params.length == 0x0) {
return SimpleKey.EMPTY;
}
if (params.length == 0x1) {
Object param = params[0x0];
if (param != null && !param.getClass().isArray()) {
return param;
}
}
return new SimpleKey(params);
}
}
Run 1
The code is well-structured and readable, with clear separation of concerns between the generate() and generateKey() methods. Nesting is minimal, with only one level of conditional logic in generateKey(). The intent is clear: generate a cache key from method parameters, with special handling for single non-array values. Action granularity is good, with one operation per line. The use of hex literals like '0x0' and '0x1' is unusual in Java code where 0 and 1 would be more conventional, slightly reducing readability. The ternary operator in generate() could be written more explicitly for better clarity. Overall, the code follows Spring framework conventions well, has appropriate Javadoc, and would be easily understood by experienced Java developers. Points deducted for unconventional hex literals and the compact ternary expression.
Run 2
The code is generally well-structured and follows Spring conventions with clear class documentation. The generate method has a clear purpose and delegates to a testable static method. However, readability suffers slightly from the use of hexadecimal notation (0x1, 0x0) for array indices and lengths, which is unusual and forces readers to mentally convert values. The ternary expression in generate() crams multiple operations into a single line, reducing clarity. The nested condition inside generateKey adds one level of nesting but remains manageable. Variable names are clear and the overall flow is logical. Could improve by using standard decimal notation and breaking the ternary into a clearer if-else block.
Run 3
The code is generally well-structured with clear separation of concerns and minimal nesting. The class has a single responsibility, and the methods are short. Intent is mostly clear, though the hexadecimal literals (0x0, 0x1) are unusual and reduce immediate readability. The suspending-function handling with Arrays.copyOf is a bit opaque without deeper Spring/Kotlin knowledge. Reading flow is natural: public API method delegates to a static utility method. Action granularity is good, with simple conditions and returns. The Javadoc is helpful but could be more concise. Overall, it's readable but slightly hindered by hexadecimal numeric literals and the Kotlin-specific conditional logic.
Run 1
Code Structure: Two focused methods clearly separate invocation handling from key generation. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive names and documentation explain the main behavior, though hexadecimal constants obscure ordinary counts and indices, and removing the final parameter for Kotlin suspending functions lacks explanation. Code length: The implementation is concise, with proportionate documentation. Action granularity: Each statement performs a focused action; the ternary combines detection and parameter adjustment but remains manageable. Reading flow: Key generation proceeds naturally through empty, single-value, and fallback cases. Minor distractions include redundant parentheses around the ternary and limited spacing between package and import declarations.
Run 2
Code Structure: Two focused methods cleanly separate parameter preparation from key generation. Nesting: Mostly flat, with early returns and only one nested conditional. Clarity of intent: Descriptive names and documentation explain the key-selection rules, but hexadecimal literals for zero and one add unnecessary cognitive overhead, and removing the final parameter for Kotlin suspending functions lacks explanation. Code length: Concise implementation; most additional length is useful documentation. Action granularity: Statements generally perform one action, although the ternary inside generateKey combines detection, parameter copying, and delegation. Reading flow: The empty, single-value, and fallback cases follow a natural sequence. Extra parentheses around the ternary and tightly grouped package/import declarations slightly reduce visual clarity.
Run 3
Code Structure: Two focused methods cleanly separate parameter adjustment from key generation. Nesting: Early returns keep control flow mostly flat, with only one shallow nested conditional. Clarity of intent: Descriptive names and documentation explain key generation, but hexadecimal literals for zero and one are distracting, and removing the Kotlin suspension parameter lacks an explanatory comment. Code length: The implementation is concise without unnecessary logic. Action granularity: Statements generally perform one action each, though the ternary inside the generateKey call combines parameter selection, copying, and delegation. Reading flow: The methods follow a natural sequence, and fallback behavior is easy to identify; extra parentheses and the wrapped ternary slightly interrupt readability.