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))) {} else {
return SimpleKey.EMPTY;
}
if (!((params.length == 1))) {} else {
Object param = params[0];
if (param != null && !param.getClass().isArray()) {
return param;
}
}
return new SimpleKey(params);
}
}
Run 1
The code's structure and public API are reasonable, but the logic in `generateKey` is heavily obscured by deliberately awkward and unnatural conditional constructs — specifically the empty `if` blocks paired with `else` branches. This inverts standard readability expectations and forces the reader to mentally 'reverse' every condition. Multi-line conditionals with excessive parentheses further reduce clarity. While the method is short and actions are generally one per line, the flow of reading is disorganized and the intent is ambiguous. The class-level Javadocs are helpful, but the method-level logic negates that advantage. Overall, the code is functionally concise but conceptually tangled, earning a low readability score.
Run 2
The code is mostly well-structured with clear class-level documentation and sensible method separation. However, readability suffers significantly in the generateKey method. The conditional logic is awkwardly inverted: 'if (!(condition)) {} else { return ... }' is a confusing pattern that obscures intent. Nesting is minimal and each action is generally on its own line, which is good. The Kotlin detection logic in the generate method is clear but slightly verbose. The method-level Javadoc for generateKey is sparse. Overall, the code has good bones but the bizarre conditional style and empty if-blocks make it harder to read than necessary. A simple 'if (params.length == 0) return SimpleKey.EMPTY;' would dramatically improve clarity.
Run 3
The code exhibits several readability issues. The generateKey method contains inverted and unnecessarily convoluted conditionals like 'if (!((params.length == 0))) {} else { return SimpleKey.EMPTY; }' which force readers to reverse logic mentally. Empty if blocks with logic in else clauses obscure intent and break natural reading flow. The method mixes multiple actions and checks across lines, reducing clarity. While the class-level Javadoc is helpful and imports are clean, the core logic is tangled and verbose for such a simple task. Nesting is shallow but the conditional style harms comprehension. The KotlinDetector array truncation uses a ternary within a method call, adding minor complexity. Action granularity is acceptable but overall structure and clarity suffer significantly from deliberate inversion of standard boolean logic and empty conditional branches.
Run 1
Code Structure: Responsibilities are logically separated between generate and generateKey, but empty if branches with logic in else blocks obscure standard guard clauses. Nesting: Mostly shallow, with one nested check for a single parameter. Clarity of intent: Names and documentation clearly describe key generation, while negated conditions and redundant parentheses make simple length checks unnecessarily confusing. Code length: Compact overall, though empty branches add avoidable syntax. Action granularity: Most lines contain one action, but the inline empty branches reduce visual clarity. Reading flow: The delegation and final fallback are natural; inverted branching interrupts the flow, and the Kotlin-specific ternary requires additional interpretation.
Run 2
Code Structure: The class is logically divided into delegation and key-generation methods, but empty if branches with inverted conditions obscure otherwise straightforward logic. Nesting: Mostly shallow, with one nested check; unnecessary else blocks add avoidable nesting. Clarity of intent: Documentation, descriptive names, and explicit return values clarify the purpose, while double parentheses, negations, and empty branches make parameter-count checks harder to interpret. Code length: Compact overall, though redundant syntax adds clutter without functionality. Action granularity: Statements generally perform one action per line; the ternary expression combines detection and parameter adjustment but remains manageable. Reading flow: Method order and early returns support natural reading, but the unusual conditional structure interrupts the flow and requires mentally reversing conditions.
Run 3
Code Structure: The class is logically divided into delegation and key-generation methods, but empty if branches with operative else blocks obscure otherwise simple logic. Nesting: Depth is modest, though the inverted conditionals introduce avoidable nesting. Clarity of intent: Documentation, method names, and constants clearly explain key generation; redundant parentheses and negations make parameter-count checks unnecessarily confusing. Code length: Overall concise, but the empty branches add needless syntax. Action granularity: Most statements perform one action, although inline empty branches and else clauses reduce visual clarity. Reading flow: The methods follow a sensible sequence, but inverted conditions interrupt natural reading, and the multiline ternary requires extra attention. Direct checks for zero and one parameter would substantially improve readability.