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) {
final int a = 2;
final int b = -1;
return generateKey((KotlinDetector.isSuspendingFunction(method) ?
Arrays.copyOf(params, params.length - (a + b)) : params));
}
/**
* Generate a key based on the specified parameters.
*/
public static Object generateKey(@Nullable Object... params) {
final int c = 1;
final int d = -1;
if (params.length == (c + d)) {
return SimpleKey.EMPTY;
}
final int e = 2;
final int f = -1;
if (params.length == (e + f)) {
final int g = 1;
final int h = -1;
Object param = params[(g + h)];
if (param != null && !param.getClass().isArray()) {
return param;
}
}
return new SimpleKey(params);
}
}
Run 1
The code is severely obfuscated with meaningless constant variables (a, b, c, d, e, f, g, h) used to perform trivial arithmetic. This destroys readability: 'params.length - (a + b)' obscures the intent of checking for suspending functions, 'params.length == (c + d)' hides a zero-length check, and 'params.length == (e + f)' hides a single-parameter check. The naming gives no semantic meaning, forcing readers to trace each constant. While the overall structure is logical and nesting is minimal, clarity of intent is nearly non-existent due to this deliberate obfuscation. Action granularity suffers because each simple operation is spread across multiple cryptic lines. Reading flow is interrupted as readers must decode arithmetic instead of understanding caching logic. The original Spring Framework code is normally clear, but this modified version is unreadable for any maintainer.
Run 2
The code structure is clear, with a logical public API and helper method, but the variable declarations (a, b, c, d, e, f, g, h) obscure intent. Nesting is shallow, which helps readability, and action granularity is acceptable. However, expressions like `params.length - (a + b)` are unnecessarily confusing. The arithmetic constants (e.g., `c + d` for 0) are a major readability problem, replacing simple literals with cryptic calculations. The Javadoc is helpful, but the code inside methods does not match its clarity. Reading flow suffers because the reader must decode minor arithmetic just to understand array indices or length comparisons. Overall, the code would be significantly clearer with direct literals and fewer intermediate variables, but it remains reasonably structured and concise.
Run 3
This code demonstrates severely degraded readability through deliberate obfuscation of basic integer literals. Simple constants like 0, 1, and 2 are replaced with arithmetic expressions using meaningless variable names (a, b, c, d, etc.), forcing the reader to mentally compute each value. The variable names convey absolutely no semantic meaning and the expressions (e.g., params.length - (a + b) where a=2 and b=-1) hide trivial operations. Each simple operation is spread across multiple lines with absurd action granularity, inflating code length dramatically. The intent of handling Kotlin suspending functions is obscured behind this obfuscation. While the package structure and general logical organization follow Spring conventions, these positive aspects are completely overwhelmed by the perverse misuse of variables for basic integers, making the code practically unreadable. Only method names and class-level Javadocs offer any clarity, serving as the sole lifelines for understanding this code.
Run 1
Code Structure: Two focused methods logically separate parameter adjustment from key creation, but unnecessary constants clutter both. Nesting: Mostly flat with early returns and only one nested conditional. Clarity of intent: Documentation explains key generation, but meaningless names a through h and arithmetic expressions obscure straightforward checks for zero or one parameter and index zero. Code length: Artificial constant declarations make otherwise compact logic unnecessarily long. Action granularity: Statements generally perform one action per line, although the ternary return combines suspension detection, array copying, and key generation. Reading flow: The empty, single, and multiple-parameter cases follow a natural sequence, but repeated arithmetic decoding interrupts comprehension.
Run 2
Code Structure: Two focused methods logically separate parameter preprocessing from key generation. Nesting: Mostly shallow, with only one nested conditional. Clarity of intent: Documentation explains the purpose, but meaningless variables a–h and arithmetic expressions obscure simple values such as 0 and 1. The Kotlin-specific parameter adjustment also lacks an explanatory comment. Code length: Unnecessary constant declarations make otherwise concise logic longer and harder to scan. Action granularity: Statements generally perform one action per line, although the ternary combines condition checking, array copying, and delegation. Reading flow: Early returns provide a natural progression through empty, single-value, and multiple-value cases, but repeated arithmetic indirection interrupts that flow.
Run 3
Code Structure: Two focused methods and early returns provide logical organization. Nesting: Mostly shallow, with only one nested conditional; the ternary is manageable. Clarity of intent: Documentation explains key generation well, but meaningless variable names a–h and arithmetic expressions obscure simple constants, array indexing, and removal of the Kotlin continuation parameter. Code length: Unnecessary constant declarations make a short algorithm substantially longer. Action granularity: Each statement generally performs one action, although the return expression combines suspension detection, array copying, and key generation. Reading flow: The empty, single-parameter, and fallback cases follow a natural sequence, but repeated arithmetic indirection interrupts comprehension. Replacing these expressions with direct literals and clarifying the Kotlin-specific adjustment would substantially improve readability.