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) {
return new DefaultCacheKeyInvocationContext<>(((AbstractJCacheKeyOperation<Annotation>) operation), target, params);
}
}
Run 1
The code is well-structured with clear class and method organization. The constructor overloads are logical and use appropriate assertion checks. Nesting is minimal except in the doGenerate method, which has a single conditional but is still readable. Variable and method names clearly convey intent (e.g., getTarget, doGenerate, cacheKeyGenerator). Code length is appropriate for the functionality — no unnecessary verbosity. Action granularity is mostly good, with each line performing one logical operation, though the condition in doGenerate spans multiple concerns (position check, varargs logic) in a single if. Reading flow is natural: field declarations, constructors, public methods, then private helpers. Minor style issues: unused imports (ArrayList is used but listed, List also, though both appear used), and a stray blank line before the return in createCacheKeyInvocationContext. Overall, this is clean, maintainable Spring framework code.
Run 2
The code is generally readable with clear intent, good structure, and appropriate method naming. It has flat nesting with only one level of conditionals inside methods, and each line performs one logical action. The class has a clear purpose as an adapter between Spring and JSR-107 key generators. However, readability is slightly reduced by a few factors: the unused method `getTarget()` appears to be dead code, the ternary-style conditional for varargs handling could be clearer, and the `createCacheKeyInvocationContext` method includes unnecessary whitespace and a type cast that obscures intent. The imports are slightly long but typical for Spring. Overall, the code follows clean code practices well but has minor clarity issues.
Run 3
The code is well-structured and readable. It follows Spring conventions, has clear field and method names, and uses constructor overloading effectively. The class responsibilities are cohesive, and the logic is relatively flat with only two conditional branches in generate(). Intent is generally clear — adapting between Spring and JCache key generators — but the createCacheKeyInvocationContext method contains an unused SuppressWarnings and a redundant cast, slightly reducing clarity. The doGenerate method handles varargs and non-varargs cases in a single loop, which slightly increases cognitive load. Overall, it is maintainable and professional code, with minor areas for improvement in explicitness and dead code removal.
Run 1
Code Structure: Constructors, delegation logic, parameter processing, and context creation are separated into focused methods. Nesting: Mostly shallow, with only a conditional inside the parameter loop. Clarity of intent: Descriptive names, Javadocs, and explicit assertions clearly communicate the adapter's purpose; mutually exclusive nullable generators and an unchecked cast add some mental overhead. Code length: Appropriately concise overall, though constructor validation is duplicated and the context-creation helper is minimal. Action granularity: Statements generally perform one action per line; the final context construction combines a cast and instantiation but remains understandable. Reading flow: Methods follow a natural progression from initialization to generation and supporting helpers. Excess blank lines, a long return statement, and minor documentation grammar issues slightly reduce polish.
Run 2
Code Structure: Constructors, delegation, parameter processing, and context creation are separated into focused methods. Nesting: Shallow overall, with only a loop containing an if/else in doGenerate. Clarity of intent: Descriptive names, documentation, and explicit assertions make the adapter's purpose clear; nullable alternative generators and an unchecked cast add minor complexity. Code length: Mostly concise, though constructor validation is duplicated and the context-creation helper is somewhat verbose for a single return. Action granularity: Each statement generally performs one action, with no crowded multi-statement lines. Reading flow: Methods follow a natural progression from initialization to delegation and helpers. Excess blank lines, the long context-construction expression, and a compound varargs condition slightly interrupt otherwise consistent formatting.
Run 3
Code Structure: Well-organized adapter with distinct constructors and focused helper methods. Nesting: Shallow overall; the loop with an inner conditional is easy to follow. Clarity of intent: Descriptive names, documentation, and explicit validation clearly explain delegation and parameter handling, though mutually exclusive nullable generators and an unchecked cast add complexity. Code length: Appropriately concise, with minor repetition in constructor validation and generator checks. Action granularity: Generally one action per line; the final context construction combines casting and instantiation but remains understandable. Reading flow: Natural progression from initialization to delegation and helpers, slightly weakened by excessive blank lines, a long return statement, and an unnecessary else after an early return.