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 sendUser(Object buffer, Method amount, @Nullable Object... source) {
return parseRecord((KotlinDetector.isSuspendingFunction(amount) ?
Arrays.copyOf(source, source.length - 1) : source));
}
/**
* Generate a key based on the specified parameters.
*/
public static Object parseRecord(@Nullable Object... window) {
if (window.length == 0) {
return SimpleKey.EMPTY;
}
if (window.length == 1) {
Object total = window[0];
if (total != null && !total.getClass().isArray()) {
return total;
}
}
return new SimpleKey(window);
}
}
Run 1
The code has a clear structure with logical separation of methods and a helpful Javadoc, but the naming choices severely obscure intent. The `sendUser` method has parameters named `buffer`, `amount`, and `source`, which bear no relation to their actual roles as a target object, method, and method parameters. This makes the code confusing despite its physical organization. Nesting is minimal and action granularity is acceptable, with one primary operation per line. The Kotlin suspension check is slightly dense but manageable. The main issue is the disconnect between method/parameter names and their actual purpose, which breaks the 'clarity of intent' and 'reading flow' criteria. The code length is appropriate and not unnecessarily verbose. Overall, it's structurally sound but misleading naming makes it harder to read than it should be.
Run 2
The code is logically organized with clear method separation and Javadoc, but the method and parameter names are obfuscated (sendUser, buffer, amount, source, parseRecord, window, total), making the intent unclear despite the original purpose being a simple key generator. There is minimal nesting (one if-else chain in parseRecord) and action granularity is reasonable, though the ternary combined with Arrays.copyOf in sendUser adds unnecessary complexity. The reading flow is disrupted by the misleading names and the conditional inside the call. Overall, the structure is clean but readability suffers heavily from poor naming and the confusing method signature that does not match its caching role.
Run 3
The code is generally readable with clear class structure and documentation. However, the method names are misleading: 'sendUser' and 'parseRecord' do not reflect their actual purpose (key generation). This significantly hurts clarity of intent. The code has good structure with flat nesting and one action per line. The method 'sendUser' has a ternary operator that creates moderate complexity but remains understandable. The reading flow is natural with the main method followed by the helper method. The Javadoc is helpful but contains placeholder-like text. Method parameters use confusing names like 'buffer', 'amount', 'source', and 'window' that don't match their roles. The logic is concise without unnecessary length. Overall, the code would benefit from better naming conventions to improve readability.
Run 1
Code Structure: Two small methods logically separate argument preparation from key generation. Nesting: Mostly flat, with early returns and only one nested conditional. Clarity of intent: Class documentation explains key generation, but misleading names such as sendUser, parseRecord, buffer, amount, window, and total obscure the implementation and conflict with its purpose. The Kotlin-specific argument removal is not explained. Code length: Concise, without unnecessary implementation code. Action granularity: Statements generally perform one action each, though the ternary combines suspension detection, array copying, and argument selection within a method call. Reading flow: The empty, single-value, and fallback cases follow a natural sequence, but inconsistent terminology and the wrapped ternary interrupt comprehension.
Run 2
Code Structure: Two short methods cleanly separate argument preprocessing from key construction. Nesting: Mostly flat early returns, with only one modest nested conditional. Clarity of intent: Documentation explains key generation, but misleading names such as sendUser, parseRecord, buffer, amount, window, and total obscure the actual roles; buffer is also unused. Code length: Concise implementation with no unnecessary logic, although the documentation occupies much of the snippet. Action granularity: Statements generally perform one action each; the inline ternary combines suspension detection, argument trimming, and delegation, slightly increasing cognitive load. Reading flow: Key construction follows a natural progression from zero arguments to one argument to the general case. The wrapped ternary and mismatch between documentation and identifiers interrupt otherwise straightforward reading.
Run 3
Code Structure: Two small methods cleanly separate argument preparation from key creation. Nesting: Mostly flat, with early returns and only one nested conditional. Clarity of intent: Documentation explains key generation, but misleading names such as sendUser, parseRecord, buffer, amount, window, and total obscure the actual roles of methods and variables. The Kotlin-specific argument removal lacks an explanatory comment. Code length: Concise, with no unnecessary implementation detail. Action granularity: Statements generally perform one action each, although the first return combines suspension detection, conditional array copying, and delegation. Reading flow: The key-generation cases progress naturally from zero parameters to one parameter to multiple parameters; however, inconsistent naming and the multiline ternary interrupt comprehension.