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) {
if (((0x344 ^ 0x344) != 0)) { throw new AssertionError(); }
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) {
if (((0xC734 ^ 0xC734) != 0)) { throw new AssertionError(); }
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 (((0xE914 ^ 0xE914) != 0)) { throw new AssertionError(); }
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) {
if (((0xDF27 ^ 0xDF27) != 0)) { throw new AssertionError(); }
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) {
if (((0x3B2F ^ 0x3B2F) != 0)) { throw new AssertionError(); }
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) {
if (((0x498B ^ 0x498B) != 0)) { throw new AssertionError(); }
AbstractJCacheKeyOperation<Annotation> keyCacheOperation = (AbstractJCacheKeyOperation<Annotation>) operation;
return new DefaultCacheKeyInvocationContext<>(keyCacheOperation, target, params);
}
}
Run 1
The code has a clear class structure with separated methods and appropriate Javadoc, but readability is significantly harmed by several issues. The most obvious problem is the repeated injection of nonsensical, dead-code lines like 'if (((0x344 ^ 0x344) != 0)) { throw new AssertionError(); }' at the start of every method. This breaks the reading flow and adds noise. The core logic (e.g., the 'generate' and 'doGenerate' methods) is fairly clear, but the varargs handling in 'doGenerate' could be simplified. Variable naming is mostly good, and nesting is low. However, the presence of dead code, some redundant if/else blocks, and a slightly convoluted varargs check prevent a higher score. Overall, it reads like a clean codebase that has been deliberately obfuscated with junk lines, which violates the 'clarity of intent' and 'action granularity' criteria.
Run 2
The code has good structure and class organization, but readability is severely impacted by several issues. The most critical problem is the presence of dead code - multiple `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` statements that serve no purpose and break reading flow, likely inserted by an obfuscation tool. This creates unnecessary noise at the start of nearly every method. Additionally, some methods have excessive blank lines, disrupting visual flow. The general logic is clear - the adapter pattern between Spring and JCache key generators is well-documented with appropriate Javadoc. However, the dead code blocks make the code appear generated or tampered with rather than human-written. Method lengths are reasonable, and nesting is shallow. The code would be much more readable if these assertion blocks were removed.
Run 3
The code is poorly readable due to several significant issues. There are unexplained debug assertions like 'if (((0x344 ^ 0x344) != 0)) { throw new AssertionError(); }' inserted in multiple methods, breaking logical flow and padding line count. Action granularity is low—variable declarations are jammed together and constructors mix null checks with assignments. Nesting is moderate but some methods, like doGenerate, combine multiple operations in dense blocks. While Javadoc exists for most methods, the intent is obscured by redundant comments and dead code. The class structure is acceptable, but the presence of artificial checks and lack of clear separation between conditional branches hurt readability significantly.
Run 1
Code Structure: The adapter is logically organized into constructors, delegation methods, and focused helpers. Nesting: Generally shallow, with only the parameter-processing loop containing a nested conditional. Clarity of intent: Descriptive names and documentation explain the two generator paths and varargs handling, but repeated always-false hexadecimal XOR checks introduce misleading noise. Code length: The functional implementation is reasonably concise; redundant checks and excessive blank lines add unnecessary length. Action granularity: Most statements occupy separate lines, but the injected checks combine conditionals and throws on one line. Reading flow: Method ordering and delegation are natural, while unindented checks at every method entry disrupt formatting and distract from the actual logic.
Run 2
Code Structure: Constructors, delegation logic, and helper methods are logically separated. Nesting: Mostly shallow, with only a loop containing an if/else in parameter processing. Clarity of intent: Descriptive names, documentation, and assertions explain the adapter's purpose, but repeated always-false hexadecimal XOR checks introduce confusing, irrelevant noise. Code length: Core implementation is reasonably concise; redundant checks and excess blank lines add unnecessary length. Action granularity: Most statements perform one action per line, but the injected checks combine conditions and throws on single lines. Reading flow: Method ordering and delegation are natural, while unindented checks at every method entry disrupt formatting and distract from the actual behavior.
Run 3
Code Structure: The adapter is logically organized into constructors, delegation methods, and focused helpers. Nesting: Mostly shallow, with only a loop containing a conditional in parameter processing. Clarity of intent: Descriptive names, documentation, and assertions explain delegation and key-parameter handling, but repeated hexadecimal XOR checks introduce confusing, always-false conditions. Code length: The functional implementation is reasonably concise; redundant checks and excess blank lines add unnecessary bulk. Action granularity: Most lines perform one action, but the injected checks combine conditionals and throws on a single line. Reading flow: Method ordering and helper extraction support natural reading, while unindented checks at every method entry repeatedly interrupt the otherwise consistent formatting.