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) {
if (((0x35DC ^ 0x35DC) != 0)) { throw new AssertionError(); }
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 (((0xDD35 ^ 0xDD35) != 0)) { throw new AssertionError(); }
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 has a clear structure with a logical class organization, separating the interface implementation from the static utility method. Nesting is minimal, with only two levels in the generateKey method. Intent is generally clear with descriptive method names and a helpful Javadoc. However, readability is significantly harmed by the injected dead code: the obfuscated assertions like 'if (((0x35DC ^ 0x35DC) != 0))' break the natural reading flow and add unnecessary length. Action granularity is mostly one action per line, but the generate method combines a conditional expression and method call on a single line, reducing clarity. The use of the ternary operator is concise but slightly complex. Overall, the structure is sound, but the unnatural assertions and slightly dense single-line logic prevent a higher score.
Run 2
The code is generally well-structured with clear separation between interface implementation and static utility method, and Javadoc improves intent clarity. However, readability is significantly hurt by the pointless defensive assertions (e.g., `if (((0x35DC ^ 0x35DC) != 0)) { throw new AssertionError(); }`), which add noise and confusion. The main `generate` method pushes multiple actions into the return expression (array copy + ternary + method call), reducing readability. Nesting in `generateKey` is shallow and logical, but the method checks two conditions before falling through. Variable names are clear, but the parameter-array manipulation feels subtle. Overall, the code is understandable but marred by unnecessary clutter and slightly dense expressions.
Run 3
The code is generally well-structured with clear intent and good readability. The class has a clear purpose, methods are short, and the logic is straightforward. However, the presence of dead code (the XOR comparison AssertionError blocks) is confusing and disrupts the reading flow. These appear to be artificially inserted and serve no functional purpose. The method generateKey uses early returns effectively, keeping the nesting minimal. The conditional with the ternary operator in the first method is slightly less readable due to combining array copying logic inline, but still acceptable. The documentation is helpful, though the overall readability is impacted by the unexplained assertion blocks.
Run 1
Code Structure: Two focused methods logically separate parameter preprocessing from key creation, but unrelated assertion statements interrupt both. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Names and documentation clearly explain key generation; opaque hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: The implementation is concise overall, although the redundant assertions add unnecessary code. Action granularity: Most lines express one action, but each assertion compresses a condition, block, and throw onto one line. Reading flow: Key-generation cases progress naturally from zero parameters to one parameter to multiple parameters. Unindented assertion lines disrupt formatting, and the multiline ternary requires some extra attention.
Run 2
Code Structure: Two focused methods logically separate parameter adjustment from key construction, but unrelated assertion guards disrupt that organization. Nesting: Mostly flat early returns, with only one modest nested conditional. Clarity of intent: Documentation, method names, and straightforward key-selection rules communicate the purpose well; hexadecimal XOR expressions obscure intent and are always false. Code length: Concise overall, although the dead assertion statements and redundant parentheses add unnecessary clutter. Action granularity: Most lines contain one action, but each assertion guard compresses a conditional and throw onto one line. Reading flow: The methods follow a natural progression from special cases to the default result, but unindented guards interrupt the otherwise consistent formatting, and the multiline ternary requires slightly more effort to parse.
Run 3
Code Structure: Two focused methods logically separate parameter preprocessing from key generation, but irrelevant assertion guards disrupt the organization. Nesting: Mostly flat early returns, with only one small nested condition. Clarity of intent: Documentation, descriptive names, and straightforward conditions clearly explain key generation; hexadecimal XOR checks obscure intent and serve no apparent purpose. Code length: The implementation is concise overall, though redundant guards and extra parentheses add unnecessary noise. Action granularity: Most lines contain a single action, but each assertion guard combines a condition and throw on one line. Reading flow: Key-generation logic reads naturally, while unindented guards and the wrapped ternary interrupt an otherwise consistent flow.