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();
final int a = 2;
final int b = -1;
if (param.getParameterPosition() == context.getAllParameters().length - (a + b) &&
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 is generally well-structured and readable. It has clear class responsibilities, logical method separation, and good Javadoc comments. The nesting level is shallow, and most methods are concise. However, the score is reduced due to the confusing expression in doGenerate: `context.getAllParameters().length - (a + b)` with unexplained variables `a` and `b` (values 2 and -1). This obscures intent. Additionally, the method `doGenerate` mixes logic (varargs check) with collection building in a single block, slightly reducing action granularity. The adapter constructors are clear, but the dual state fields (`keyGenerator` vs `cacheKeyGenerator`) introduce minor ambiguity. Overall, it is maintainable and clean but has localized readability issues.
Run 2
The code is generally well-structured, with clear class responsibilities, good use of constructors, and meaningful method names. Imports are organized, and Javadocs explain intent. However, readability is hindered by a few issues: the `doGenerate` method contains magic numbers and unclear logic (`a` and `b` constants) that obscure the varargs handling; the method has moderate nesting and mixes conditionals with collection logic. While most actions are one per line, some expressions are dense. The `generate` method has a slightly tangled flow due to nested if/else and casting. Overall, the structure and intent are clear, but the presence of unexplained constants and somewhat complex control flow reduces readability from excellent to good.
Run 3
The code is generally well-structured with clear class responsibilities, logical method organization, and good use of Javadoc. It reads naturally: constructors, getters, core logic, then private helpers. Nesting is shallow, and most lines perform one clear action. However, readability is reduced by a few issues: the magic numbers 'a' and 'b' in the varargs check are unintuitive and obscure the logic (e.g., why 'length - (2 + -1)'?). The conditional logic for handling varargs parameters could be extracted into a named method to improve intent clarity. Additionally, the null-check and exception messages are clear, but the dual key generator fields (keyGenerator vs cacheKeyGenerator) require careful reading to understand their mutual exclusivity. Overall, the code is professional and maintainable but would benefit from clearer varargs handling and eliminating magic numbers.
Run 1
Code Structure: Well-organized adapter with distinct constructors and focused helper methods; minor constructor duplication. Nesting: Shallow conditionals and a single loop keep control flow manageable. Clarity of intent: Descriptive names, documentation, and explicit assertions explain delegation and parameter handling. However, constants a = 2 and b = -1 obscure a simple last-parameter check, and varargs expansion lacks an explanatory comment. Code length: Generally concise, though redundant constants and repeated initialization add unnecessary lines. Action granularity: Statements consistently perform one action per line. Reading flow: Methods progress naturally from construction to delegation and context creation, with consistent formatting; the multiline varargs condition and generic cast introduce modest reading friction.
Run 2
Code Structure: Well-organized adapter with focused constructors and helper methods separating delegation, parameter processing, and context creation. Nesting: Generally shallow; the loop with an embedded conditional remains easy to follow. Clarity of intent: Descriptive names, documentation, and assertions communicate the purpose clearly, but the unexplained constants a and b and expression (a + b) obscure a simple last-parameter check. Code length: Mostly concise, with minor constructor duplication and unnecessary constants. Action granularity: Statements generally perform one action per line, making execution easy to trace. Reading flow: Methods follow a natural progression from initialization to delegation and supporting helpers; the compound varargs condition and generic cast introduce modest cognitive overhead.
Run 3
Code Structure: Constructors, delegation, parameter processing, and context creation are cleanly separated into focused methods. Nesting: Control flow remains shallow, with only a conditional inside the parameter loop. Clarity of intent: Descriptive class and method names, documentation, and assertions clearly communicate the adapter's purpose; however, the arbitrary constants a = 2 and b = -1 obscure the straightforward last-parameter check. Code length: Mostly concise, though those constants and some repeated validation add minor verbosity. Action granularity: Statements generally perform one action per line, making execution easy to follow. Reading flow: The progression from construction to target selection, generation, and helpers is natural. The multiline varargs condition and generic cast introduce modest cognitive overhead, but the unexplained arithmetic is the main readability weakness.