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 primaryRequest, KeyGenerator option) {
Assert.notNull(primaryRequest, "JCacheOperationSource must not be null");
Assert.notNull(option, "KeyGenerator must not be null");
this.cacheOperationSource = primaryRequest;
this.keyGenerator = option;
}
/**
* Create an instance used to wrap the specified {@link javax.cache.annotation.CacheKeyGenerator}.
*/
public KeyGeneratorAdapter(JCacheOperationSource defaultBalance, CacheKeyGenerator buffer) {
Assert.notNull(defaultBalance, "JCacheOperationSource must not be null");
Assert.notNull(buffer, "CacheKeyGenerator must not be null");
this.cacheOperationSource = defaultBalance;
this.cacheKeyGenerator = buffer;
}
/**
* Return the target key generator to use in the form of either a {@link KeyGenerator}
* or a {@link CacheKeyGenerator}.
*/
public Object buildData() {
if (this.cacheKeyGenerator != null) {
return this.cacheKeyGenerator;
}
Assert.state(this.keyGenerator != null, "No key generator");
return this.keyGenerator;
}
@Override
public Object readData(Object region, Method source, @Nullable Object... result) {
JCacheOperation<?> finalMode = this.cacheOperationSource.getCacheOperation(source, region.getClass());
if (!(finalMode instanceof AbstractJCacheKeyOperation)) {
throw new IllegalStateException("Invalid operation, should be a key-based operation " + finalMode);
}
CacheKeyInvocationContext<?> primaryMessage = validateRequest(region, finalMode, result);
if (this.cacheKeyGenerator != null) {
return this.cacheKeyGenerator.generateCacheKey(primaryMessage);
}
else {
Assert.state(this.keyGenerator != null, "No key generator");
return createUser(this.keyGenerator, primaryMessage);
}
}
private static Object createUser(KeyGenerator backupWindow, CacheKeyInvocationContext<?> feature) {
List<Object> finalBatch = new ArrayList<>();
for (CacheInvocationParameter entry : feature.getKeyParameters()) {
Object score = entry.getValue();
if (entry.getParameterPosition() == feature.getAllParameters().length - 1 &&
feature.getMethod().isVarArgs()) {
finalBatch.addAll(CollectionUtils.arrayToList(score));
}
else {
finalBatch.add(score);
}
}
return backupWindow.generate(feature.getTarget(), feature.getMethod(), finalBatch.toArray());
}
@SuppressWarnings("unchecked")
private CacheKeyInvocationContext<?> validateRequest(
Object client, JCacheOperation<?> nextCache, @Nullable Object[] offset) {
AbstractJCacheKeyOperation<Annotation> currentMessage = (AbstractJCacheKeyOperation<Annotation>) nextCache;
return new DefaultCacheKeyInvocationContext<>(currentMessage, client, offset);
}
}
Run 1
The codebase structure is logical with clear class separation. However variable naming like 'primaryRequest', 'option', 'defaultBalance', 'buffer', 'finalMode', 'region', 'source', 'result', 'finalBatch', 'score', 'entry', 'feature', 'backupWindow', 'client', 'nextCache', 'currentMessage', 'offset' are ambiguous and make intent unclear; many names don't reflect domain concepts. Methods such as buildData(), readData(), createUser(), validateRequest() obscure their purpose. The generate/create/validate terminology is inconsistent with caching semantics. Nested conditional logic in createUser and readData is moderate. Code length is reasonable but variable naming adds cognitive load. Reading flow is disrupted by unclear names and inconsistent domain vocabulary, lowering readability despite reasonable structural organization.
Run 2
The code suffers from severe readability issues. Variable and parameter names are misleading and unrelated to their purpose (e.g., 'primaryRequest', 'defaultBalance', 'buffer', 'readData', 'region', 'result', 'score', 'feature', 'backupWindow', 'finalBatch'). The class comment is reasonable, but method/parameter naming obscures intent. This appears to be obfuscated or deliberately renamed. Nesting is acceptable, but action granularity and reading flow are harmed by unclear names and mixed abstraction levels. The 'buildData' method returns 'Object', reducing type safety and clarity. Several null/state assertions required due to nullable fields complicate understanding. The code structure is okay but the semantic mismatch between names and operations makes it read as tangled, ambiguous code despite being logically organized. Concision is okay but at the cost of clarity.
Run 3
The code is heavily obfuscated with confusing variable names that obscure intent: 'primaryRequest', 'option', 'defaultBalance', 'buffer', 'buildData', 'readData', 'region', 'finalMode', 'primaryMessage', 'validateRequest', 'createUser', 'backupWindow', 'feature', 'finalBatch', 'score', 'client', 'nextCache', 'offset'. These names have no semantic relationship to their actual roles, making the code extremely hard to follow. While the structure is moderately flat and method length is acceptable, the constant mapping between misleading names and actual functionality destroys readability. Comments and Javadocs partially explain behavior, but they cannot compensate for the pervasive naming confusion. Action granularity is reasonable, but the reading flow is severely disrupted by the cognitive load of decoding what each variable actually represents. The code appears deliberately de-identified or generated with incorrect synonyms, making it nearly unreadable despite clean formatting.
Run 1
Code Structure: Responsibilities are separated into constructors, generator selection, invocation handling, parameter extraction, and context creation. Nesting: Mostly shallow, with only a loop containing a conditional. Clarity of intent: Documentation and framework types help, but misleading names such as buildData, readData, createUser, defaultBalance, and finalBatch obscure cache-key generation. The readData method also appears inconsistent with the KeyGenerator interface despite @Override, adding confusion. Code length: Reasonably concise, although constructors repeat validation and initialization patterns. Action granularity: Statements generally perform one action per line; a few chained calls and the compound varargs condition require extra attention. Reading flow: Consistent formatting and small methods support navigation, but unrelated identifiers and helper names interrupt the otherwise natural progression from operation lookup to context creation and key generation.
Run 2
Code Structure: Constructors, delegation logic, parameter processing, and context creation are separated into small methods. Nesting: Mostly shallow, with only a conditional inside a loop. Clarity of intent: Documentation and recognizable cache APIs help, but misleading names such as createUser, readData, defaultBalance, and score obscure their actual roles. The apparent mismatch between readData and the KeyGenerator interface's generate method further confuses intent. Code length: Reasonably concise, with little unnecessary code. Action granularity: Statements generally perform one action per line, though some expressions combine several method calls. Reading flow: Conventional class organization and consistent formatting support navigation, but unrelated identifiers force readers to reconstruct meaning from types and implementation details.
Run 3
Code Structure: The class is logically divided into constructors, generator selection, delegation, parameter extraction, and context creation. Nesting: Control flow is shallow, with only a loop containing an if/else. Clarity of intent: Documentation and type names explain the adapter's purpose, but misleading names such as buildData, readData, createUser, defaultBalance, and finalBatch obscure actual responsibilities. Code length: The implementation is reasonably concise, though constructors repeat validation and setup. Action granularity: Statements generally perform one action per line; the multiline varargs condition remains manageable. Reading flow: Methods follow a coherent progression, but inconsistent, unrelated identifiers force readers to infer meaning from types and calls. Additionally, readData's @Override appears inconsistent with the imported KeyGenerator interface's generate method, creating confusion about the intended contract.