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) { 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 class-level purpose and follows standard Java conventions for a simple key generator, but its layout is significantly compromised by compressed formatting. Multiple statements are packed onto single lines, and the opening brace of class methods is placed on the same line as the previous statement, disrupting natural reading flow. Nesting is shallow, which is good, but the single method `generateKey` combines multiple actions and returns on one line, violating action granularity and reducing clarity of intent. The logic itself is straightforward—delegating to a static method and handling edge cases—but the irregular indentation and lack of line breaks make it harder to scan. While not tangled, the structure feels cramped and would benefit from conventional formatting and separation of statements to improve readability.
Run 2
The code has meaningful identifiers and some documentation, but formatting severely harms readability. Multiple statements are crammed onto single lines (e.g., the interface declaration and the @Override method), and several closing braces share lines with the next 'if' statement. This violates the 'one action per line' and 'reading flow' criteria. The nested 'if' inside the single-parameter check adds some depth but is not extreme. The Kotlin suspending-function logic is concise but slightly hard to follow due to the ternary embedded in the method call. Overall, the logic itself is simple, but the disorganized layout makes it unnecessarily difficult to scan.
Run 3
The code is generally readable but has several style issues. The structure is logical with clear class purpose, but the dense formatting hurts readability. Multiple statements are packed onto single lines: `if (params.length == 0) { return SimpleKey.EMPTY;` and nested conditions are compressed together. The import statement is also crammed onto one line rather than separated. The action granularity violates best practices by combining multiple actions per line. Intent is clear from the class name and Javadoc, and the method logic is straightforward. Nesting is shallow (only one level deep), which is good. The conditional expression using KotlinDetector adds slight complexity but is understandable. Overall length is appropriate for the functionality. The code would read more naturally with proper line breaks, expanded braces, and one statement per line. The core algorithm is simple and well-documented, but formatting choices make it feel more tangled than necessary.
Run 1
Code Structure: Two focused methods logically separate parameter normalization from key creation, but compressed declarations and braces obscure that organization. Nesting: Shallow overall, with only one nested conditional. Clarity of intent: Descriptive names and documentation explain key generation well; the Kotlin-specific parameter adjustment is less obvious. Code length: The implementation is concise without unnecessary logic, and the documentation adds useful context. Action granularity: Several imports, declarations, returns, and conditional boundaries share lines, making individual operations harder to distinguish. Reading flow: Early returns provide a natural decision sequence, but inconsistent formatting, inline braces, and the split ternary expression interrupt scanning. Conventional line breaks and indentation would substantially improve readability.
Run 2
Code Structure: Two focused methods logically separate parameter preparation from key generation, but compressed imports and braces obscure boundaries. Nesting: Shallow overall, with only one nested conditional; early returns keep complexity low. Clarity of intent: Descriptive names and documentation explain key generation well, although excluding the final Kotlin suspending-function parameter is unexplained. Code length: The implementation is appropriately concise without substantial redundancy. Action granularity: Several declarations, conditionals, returns, and closing braces share lines, making individual actions harder to distinguish. Reading flow: The decision sequence is natural, but inconsistent formatting, crowded method endings, and the multiline ternary interrupt scanning.
Run 3
Code Structure: Two focused methods separate parameter normalization from key creation, but compressed imports and braces obscure their organization. Nesting: Shallow overall, with only one nested conditional, though crowded closing braces make boundaries harder to follow. Clarity of intent: Descriptive names and documentation explain key generation well; the Kotlin-specific parameter adjustment is less obvious without context. Code length: The implementation is appropriately short, and most documentation is useful. Action granularity: Several declarations, conditionals, and returns share lines, reducing scanability. Reading flow: The logic follows a natural sequence from zero parameters to one parameter to the general case, but inconsistent formatting interrupts that flow.