Source code
package org.springframework.cache.jcache.interceptor;
import java.lang.annotation.Annotation;
import java.lang.reflect.Method;
import java.util.ArrayList; import java.util.List; import javax.cache.annotation.CacheInvocationParameter; import javax.cache.annotation.CacheKeyGenerator;
import javax.cache.annotation.CacheKeyInvocationContext; import org.jspecify.annotations.Nullable; import org.springframework.cache.interceptor.KeyGenerator;
import org.springframework.util.Assert; import org.springframework.util.CollectionUtils;
/**
* Spring's {@link KeyGenerator} implementation that either delegates to a standard JSR-107
* {@link javax.cache.annotation.CacheKeyGenerator}, or wrap a standard {@link KeyGenerator}
* so that only relevant parameters are handled.
*
* @author Stephane Nicoll
* @author Juergen Hoeller
* @since 4.1
*/
class KeyGeneratorAdapter implements KeyGenerator { private final JCacheOperationSource cacheOperationSource;
private @Nullable KeyGenerator keyGenerator;
private @Nullable CacheKeyGenerator cacheKeyGenerator;
/**
* Create an instance with the given {@link KeyGenerator} so that {@link javax.cache.annotation.CacheKey}
* and {@link javax.cache.annotation.CacheValue} are handled according to the spec.
*/
public KeyGeneratorAdapter(JCacheOperationSource cacheOperationSource, KeyGenerator target) {
Assert.notNull(cacheOperationSource, "JCacheOperationSource must not be null"); Assert.notNull(target, "KeyGenerator must not be null");
this.cacheOperationSource = cacheOperationSource;
this.keyGenerator = target; } /**
* Create an instance used to wrap the specified {@link javax.cache.annotation.CacheKeyGenerator}.
*/
public KeyGeneratorAdapter(JCacheOperationSource cacheOperationSource, CacheKeyGenerator target) {
Assert.notNull(cacheOperationSource, "JCacheOperationSource must not be null");
Assert.notNull(target, "CacheKeyGenerator must not be null");
this.cacheOperationSource = cacheOperationSource; this.cacheKeyGenerator = target; } /**
* Return the target key generator to use in the form of either a {@link KeyGenerator}
* or a {@link CacheKeyGenerator}.
*/
public Object getTarget() {
if (this.cacheKeyGenerator != null) { return this.cacheKeyGenerator;
} Assert.state(this.keyGenerator != null, "No key generator"); return this.keyGenerator;
} @Override
public Object generate(Object target, Method method, @Nullable Object... params) { JCacheOperation<?> operation = this.cacheOperationSource.getCacheOperation(method, target.getClass());
if (!(operation instanceof AbstractJCacheKeyOperation)) {
throw new IllegalStateException("Invalid operation, should be a key-based operation " + operation); }
CacheKeyInvocationContext<?> invocationContext = createCacheKeyInvocationContext(target, operation, params);
if (this.cacheKeyGenerator != null) { return this.cacheKeyGenerator.generateCacheKey(invocationContext);
}
else { Assert.state(this.keyGenerator != null, "No key generator");
return doGenerate(this.keyGenerator, invocationContext); }
} private static Object doGenerate(KeyGenerator keyGenerator, CacheKeyInvocationContext<?> context) {
List<Object> parameters = new ArrayList<>(); for (CacheInvocationParameter param : context.getKeyParameters()) {
Object value = param.getValue(); if (param.getParameterPosition() == context.getAllParameters().length - 1 && context.getMethod().isVarArgs()) {
parameters.addAll(CollectionUtils.arrayToList(value));
}
else { parameters.add(value);
}
}
return keyGenerator.generate(context.getTarget(), context.getMethod(), parameters.toArray()); }
@SuppressWarnings("unchecked")
private CacheKeyInvocationContext<?> createCacheKeyInvocationContext(
Object target, JCacheOperation<?> operation, @Nullable Object[] params) {
AbstractJCacheKeyOperation<Annotation> keyCacheOperation = (AbstractJCacheKeyOperation<Annotation>) operation;
return new DefaultCacheKeyInvocationContext<>(keyCacheOperation, target, params);
} }
Run 1
The code has significant readability issues. Structure suffers from inconsistent formatting, with multiple statements crammed onto single lines and method declarations, closing braces, and Javadoc comments merged together. Nesting is minimal and acceptable, but the flow is disrupted by poor spacing and indentation. Intent is partially clear due to Javadoc and method names, but the compressed formatting obscures the logic. Code length is reasonable, but the lack of line breaks makes it feel dense and difficult to scan. Action granularity is violated repeatedly—multiple operations occur on single lines, especially in constructors, getTarget(), and doGenerate(). Reading flow is disorganized, forcing the reader to mentally separate actions that should be visually distinct. While the underlying logic is straightforward, the presentation substantially undermines readability.
Run 2
The code exhibits severe readability issues. The most critical problem is formatting: multiple class members, method signatures, and statements are crammed onto single lines (e.g., field declarations, constructor bodies, getTarget() and generate() methods). This directly violates the 'one action per line' and 'reading flow' criteria, forcing the reader to parse multiple logical units simultaneously. Import statements are similarly compressed onto one line. Braces are inconsistently placed, with closing braces on the same line as subsequent code, making block structure hard to follow visually. The logic itself is not deeply nested, but the flattened, compressed format creates ambiguity about where methods begin and end. Some code is naturally structured (the doGenerate method is more reasonably formatted), but overall the inconsistent and compact style makes the code extremely difficult to scan and understand. The intent (adapting key generators) is somewhat evident from comments, but the presentation obscures the structure and increases cognitive load significantly. This would be nearly unreadable for most developers without reformatting.
Run 3
The code has severe readability issues due to poor formatting. Multiple statements are crammed onto single lines, such as field declarations, Assert statements, and method closing brackets. Imports are also grouped incorrectly, with multiple imports on one line. This violates the 'one action per line' principle and disrupts natural reading flow. While the class structure itself is logical (adapter pattern, constructor overloading), the tangled formatting makes it hard to parse quickly. The method bodies are generally small, and nesting is not overly deep, which helps somewhat. However, the inconsistent indentation and compacted code significantly reduce clarity of intent. Overall, the code fails to meet basic formatting standards, making it unnecessarily difficult to read despite sound underlying architecture.
Run 1
Code Structure: Constructors, delegation methods, and context creation are logically separated, but compressed declarations and adjacent method boundaries obscure that organization. Nesting: Mostly shallow, with only a loop containing a conditional, making control flow manageable. Clarity of intent: Descriptive class, method, and variable names plus documentation clearly communicate key-generator adaptation; the varargs condition requires closer inspection. Code length: The implementation is reasonably concise without substantial redundancy, although compressed formatting does not improve readability. Action granularity: Multiple imports, assertions, assignments, declarations, and returns share lines, making individual actions harder to scan. Reading flow: Inconsistent whitespace, inline braces, and comments or annotations attached to preceding method endings interrupt an otherwise natural progression from construction to delegation and parameter processing.
Run 2
Code Structure: Constructors, delegation methods, and context creation are logically separated, but compressed formatting obscures their boundaries. Nesting: Generally shallow, with only a loop containing a conditional; complexity is manageable. Clarity of intent: Descriptive names, documentation, and assertions clearly explain the adapter's purpose and generator selection, though the generic cast requires closer inspection. Code length: Appropriately concise for its responsibilities, without substantial unnecessary logic. Action granularity: Multiple imports, assertions, assignments, and control-flow statements share lines, making individual actions harder to scan. Reading flow: Inconsistent line breaks, braces attached to subsequent declarations, and crowded method bodies repeatedly interrupt otherwise natural execution flow. Overall, the underlying design is readable, but poor formatting significantly reduces accessibility.
Run 3
Code Structure: Constructors and focused helper methods provide logical organization, but compressed declarations and method boundaries obscure it. Nesting: Mostly shallow, with only a loop containing a conditional, so control flow remains manageable. Clarity of intent: Descriptive class, method, and variable names plus Javadoc clearly explain the adapter's purpose and delegation behavior. Code length: The implementation is reasonably concise without substantial redundancy. Action granularity: Multiple imports, assertions, assignments, and control-flow statements share lines, making individual actions harder to distinguish. Reading flow: Inconsistent spacing, inline braces, and comments or annotations attached to preceding method endings disrupt scanning. Overall, the underlying design is readable, but poor formatting significantly reduces accessibility.