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() {
{int lI0O_5dcdeb87=0x72A5;lI0O_5dcdeb87=((lI0O_5dcdeb87&0)==0)?(((lI0O_5dcdeb87^lI0O_5dcdeb87)==0)?0:1):2;}
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 reasonable structure and naming, but a critical bug in the getTarget() method contains an obfuscated, meaningless line with a randomly generated variable name and a no-op conditional loop. This severely damages readability, violating clarity of intent and reading flow. Additionally, the class-level Javadoc contains grammatical errors ('or wrap' should be 'or wraps'), and the generate method performs multiple operations per line (type cast, method call, exception throwing) reducing action granularity. The createCacheKeyInvocationContext method is concise but the unchecked cast adds noise. The generic type usage is complex but acceptable. Overall, while the core logic is understandable, the obfuscated dead code and compression of actions make it difficult to read and maintain.
Run 2
The code is generally structured and follows Spring conventions, but has a notable readability issue: an unexplained artifact line in getTarget() containing obfuscated logic (`{int lI0O...}`). This breaks the reading flow and clarity of intent. Otherwise, the class uses clear naming, flat structure, minimal nesting, and concise methods with reasonable action granularity. Constructors and null checks are straightforward, and the main generate() method is easy to follow. The varargs handling in doGenerate() is slightly dense but acceptable. Overall, it’s readable except for the stray obfuscated line.
Run 3
The code is generally well-structured with clear class and method organization. It has reasonable nesting depth (mostly 1-2 levels), and intent is mostly clear through descriptive method names and Javadoc. However, there's a significant readability issue: an injected obfuscated line in getTarget() that appears to be dead code and breaks flow. The varargs handling logic in doGenerate is slightly complex with conditional collection handling. Constructor overloading is clear, and null-check assertions improve clarity. Overall readable but the obfuscated line and minor complexity in parameter handling prevent a higher score.
Run 1
Code Structure: Well-organized adapter with distinct constructors and focused helper methods, except for an unrelated block in getTarget(). Nesting: Generally shallow; the parameter loop contains manageable conditional nesting, but the injected block uses unnecessarily nested ternaries. Clarity of intent: Descriptive names, documentation, and assertions clarify key-generation behavior; the cryptic variable and meaningless bitwise expressions obscure intent locally. Code length: Mostly concise, with minor constructor duplication and an unnecessary computation block. Action granularity: Normally one action per line, but the injected block compresses declaration, assignment, and conditional expressions onto one line. Reading flow: Methods follow a logical progression and use consistent formatting, interrupted sharply by the unindented, obfuscated block. Overall, the main implementation is readable, but the conspicuous dead computation reduces clarity and consistency.
Run 2
Code Structure: Constructors and focused helper methods organize the adapter logically, but getTarget contains an unrelated obfuscated block. Nesting: Most methods are shallow; the parameter loop has manageable conditional nesting, while the injected nested ternary adds needless complexity. Clarity of intent: Descriptive names, documentation, and assertions explain delegation and parameter handling well; the cryptic variable and redundant bitwise expressions obscure intent locally. Code length: Mostly concise, with some repeated initialization checks and unnecessary dead computation. Action granularity: Normal code uses one action per line, but the obfuscated block compresses declaration, assignment, and nested expressions into one line. Reading flow: Delegation and helper extraction provide a natural progression, interrupted sharply by the unindented, irrelevant block.
Run 3
Code Structure: The adapter is logically divided into constructors, delegation methods, parameter handling, and context creation, but an unrelated block disrupts getTarget(). Nesting: Most methods are shallow; the parameter loop has manageable nesting, while the injected nested ternary is unnecessarily complex. Clarity of intent: Descriptive names, documentation, and assertions explain the adapter's purpose, but the cryptic variable and meaningless bitwise expressions obscure intent locally. Code length: The functional implementation is reasonably concise, although the unrelated block adds needless code. Action granularity: Most statements perform one action per line; the injected block compresses declaration, assignment, and conditional expressions onto one line. Reading flow: Method organization and consistent formatting generally support natural reading, but the unindented, dense block sharply interrupts that flow.