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) {
{int lI0O_e209bccf=(0xD232^0xD232);switch(lI0O_e209bccf){case 0:lI0O_e209bccf|=0;break;default:lI0O_e209bccf&=0;}}
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 well-structured with clear separation of concerns and logical organization. Nesting is minimal with only a single conditional level in generateKey. Intent is clearly communicated through descriptive method names and Javadoc. Code length is concise without unnecessary verbosity. However, the presence of an obfuscated switch statement with XOR operations and meaningless variable names significantly hurts readability - this appears to be injected or generated code that serves no purpose and makes the flow harder to follow. Without this artifact, the code would be exemplary.
Run 2
The code is generally readable for its small size, but several factors reduce its clarity. The class structure and method purpose are clear, with a straightforward single-method implementation. However, the presence of obfuscated-looking code in the generateKey method (an irrelevant switch statement with a bitwise operation) significantly harms readability and intent. Nesting is low, which is good, and the action granularity is mostly one action per line. The use of varargs with @Nullable is idiomatic for this Spring context. The conditional expression in the main generate method is acceptable but slightly dense. The length of the method is concise, but the unnecessary switch statement adds confusion. Overall, the code would be highly readable if that artifact were removed, as it violates the principle of clear intent and introduces a non-standard construct that gives the impression of obfuscation.
Run 3
The code is generally readable with clear intent and logical structure. Class-level documentation is thorough, method names are descriptive, and the single public interface method is concise. However, readability is hurt by the odd obfuscated line that appears to do nothing, likely an anti-tampering or bytecode artifact. The nested conditional in generateKey is moderately deep but acceptable. There is an unaesthetic opening brace placement in generateKey, and the ternary in generate() slightly reduces clarity. Overall, the core logic is readable, but the unnecessary noise brings the score down.
Run 1
1. Code Structure: The class and two methods are logically organized, but an unrelated no-op block disrupts the key-generation logic. 2. Nesting: The meaningful logic uses shallow nesting and early returns; the injected switch adds unnecessary complexity. 3. Clarity of intent: Documentation and descriptive method names explain key generation well, but the cryptic variable, hexadecimal XOR, and redundant assignments obscure the injected block's purpose. 4. Code length: Most code is concise, although the no-op block adds entirely unnecessary content. 5. Action granularity: Normal statements are clearly separated, but the injected block compresses declaration, switch cases, assignments, and breaks onto one line. 6. Reading flow: The main logic progresses naturally from zero parameters to one parameter to a composite key; the unindented, obfuscated block abruptly interrupts that flow.
Run 2
Code Structure: The class is logically divided into delegation and key-generation methods, but an unrelated obfuscated block disrupts that organization. Nesting: The meaningful logic is shallow, with straightforward conditionals; the injected block adds unnecessary scope and switch nesting. Clarity of intent: Documentation and descriptive method names explain key generation clearly, while the cryptic variable, hexadecimal XOR, and ineffective bitwise operations obscure intent. Code length: The functional implementation is concise, but the no-op block adds unnecessary code. Action granularity: Most statements occupy separate lines, whereas the entire injected block compresses declaration, branching, assignments, and breaks onto one line. Reading flow: Early returns make the main logic easy to follow, and the Kotlin-specific ternary is reasonably readable, but the poorly formatted block abruptly interrupts the flow.
Run 3
Code Structure: The class is logically organized into delegation and key-generation methods, but an unrelated obfuscated block disrupts that structure. Nesting: Most logic is shallow with early returns; the single-parameter check adds modest nesting, while the inserted switch adds unnecessary complexity. Clarity of intent: Documentation, method names, and straightforward conditions clearly explain key generation, but the cryptic variable, hexadecimal XOR, and no-op assignments obscure intent. Code length: The functional implementation is concise, although the redundant switch block adds needless code. Action granularity: Normal statements perform one action per line; the obfuscated block compresses declarations, branching, assignments, and breaks onto one line. Reading flow: The main algorithm progresses naturally from empty parameters to a single usable parameter to a composite key, but the unformatted block abruptly interrupts that flow. The Kotlin-specific ternary is compact and reasonably understandable.