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 a, KeyGenerator b) {
Assert.notNull(a, "JCacheOperationSource must not be null");
Assert.notNull(b, "KeyGenerator must not be null");
this.cacheOperationSource = a;
this.keyGenerator = b;
}
/**
* Create an instance used to wrap the specified {@link javax.cache.annotation.CacheKeyGenerator}.
*/
public KeyGeneratorAdapter(JCacheOperationSource c, CacheKeyGenerator d) {
Assert.notNull(c, "JCacheOperationSource must not be null");
Assert.notNull(d, "CacheKeyGenerator must not be null");
this.cacheOperationSource = c;
this.cacheKeyGenerator = d;
}
/**
* Return the target key generator to use in the form of either a {@link KeyGenerator}
* or a {@link CacheKeyGenerator}.
*/
public Object a() {
if (this.cacheKeyGenerator != null) {
return this.cacheKeyGenerator;
}
Assert.state(this.keyGenerator != null, "No key generator");
return this.keyGenerator;
}
@Override
public Object b(Object e, Method f, @Nullable Object... g) {
JCacheOperation<?> h = this.cacheOperationSource.getCacheOperation(f, e.getClass());
if (!(h instanceof AbstractJCacheKeyOperation)) {
throw new IllegalStateException("Invalid operation, should be a key-based operation " + h);
}
CacheKeyInvocationContext<?> i = d(e, h, g);
if (this.cacheKeyGenerator != null) {
return this.cacheKeyGenerator.generateCacheKey(i);
}
else {
Assert.state(this.keyGenerator != null, "No key generator");
return c(this.keyGenerator, i);
}
}
private static Object c(KeyGenerator j, CacheKeyInvocationContext<?> k) {
List<Object> l = new ArrayList<>();
for (CacheInvocationParameter m : k.getKeyParameters()) {
Object n = m.getValue();
if (m.getParameterPosition() == k.getAllParameters().length - 1 &&
k.getMethod().isVarArgs()) {
l.addAll(CollectionUtils.arrayToList(n));
}
else {
l.add(n);
}
}
return j.generate(k.getTarget(), k.getMethod(), l.toArray());
}
@SuppressWarnings("unchecked")
private CacheKeyInvocationContext<?> d(
Object o, JCacheOperation<?> p, @Nullable Object[] q) {
AbstractJCacheKeyOperation<Annotation> r = (AbstractJCacheKeyOperation<Annotation>) p;
return new DefaultCacheKeyInvocationContext<>(r, o, q);
}
}
Run 1
This code is difficult to read due to systematically cryptic variable and method names. Parameters like 'a', 'b', 'c', 'd', 'e', 'f', 'g' and local variables like 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r' give no indication of their purpose. Method names 'a()', 'b()', 'c()', 'd()' are equally uninformative. This severely undermines clarity of intent and reading flow, making the logic unnecessarily hard to follow. The structure itself is logical and moderately nested, and action granularity is reasonable, but the pervasive opaque naming fails to communicate what the code does. The class-level Javadoc and field names are clear, but they do not compensate for the unreadability of the method bodies. Overall, the code requires substantial effort to decipher despite its relatively short length.
Run 2
The code suffers from severely degraded readability due to meaningless single-letter variable and method names (e.g., a, b, c, d, e, f, g). This obscures intent and forces the reader to infer purpose from context. The logic is nested within conditional blocks and private helper methods, though not deeply, the flow is unnatural. Method names like 'a()', 'b()', 'c()', and 'd()' give no indication of their functionality, violating clarity of intent. Parameter names provide no semantic value, making the code ambiguous and difficult to follow. While the class structure is coherent and not overly long, the naming choices drastically reduce readability. Action granularity is acceptable but overall the code reads like obfuscated source rather than maintainable production code. Without meaningful names, even simple operations become hard to parse.
Run 3
The code suffers from severe readability issues. Variable and method names are meaningless (e.g., 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r'), making the intent very hard to discern. While the class structure is logical, the naming destroys clarity of intent and reading flow. Nesting is acceptable but action granularity is reduced by cryptic names. The code is concise but this comes at a great cost to understandability. The Javadocs exist but don't compensate for the obfuscated method names and parameters.
Run 1
Code Structure: Constructors, delegation logic, parameter processing, and context creation are separated into focused methods. Nesting: Mostly shallow, with only a loop containing an if/else. Clarity of intent: Class documentation and descriptive framework types help, but single-letter method names and parameters severely obscure responsibilities and data flow. The apparent mismatch between @Override method b and KeyGenerator.generate also creates confusion. Code length: Reasonably concise, without substantial duplication beyond constructor validation. Action granularity: Statements generally perform one action per line, and the multiline condition is manageable. Reading flow: Conventional member ordering and formatting support navigation, but calls to a, b, c, and d require readers to repeatedly inspect implementations to understand their meaning.
Run 2
Code Structure: Constructors, delegation logic, parameter processing, and context creation are logically separated into small methods. Nesting: Mostly shallow, with only a loop containing an if/else; guard clauses keep control flow manageable. Clarity of intent: Class documentation and descriptive field/type names explain the adapter's purpose, but single-letter method and parameter names severely obscure individual operations and data roles. Code length: Reasonably concise, with little unnecessary implementation code; constructor duplication is minor. Action granularity: Generally one statement per line, making assignments, validation, and returns easy to distinguish. Reading flow: Consistent formatting and method boundaries support navigation, but opaque names force readers to repeatedly infer relationships between calls and variables. Overall, the organization is readable, but naming significantly undermines comprehension.
Run 3
Code Structure: Constructors, delegation, parameter processing, and context creation are separated into focused methods. Nesting: Generally shallow; the loop with an internal conditional is easy to follow. Clarity of intent: Class documentation and descriptive field names explain the adapter, but single-letter method names and parameters significantly obscure individual operations. The overridden method named b also conflicts with the expected KeyGenerator.generate contract, creating confusion. Code length: Reasonably concise, with little unnecessary implementation code. Action granularity: Statements generally perform one action per line, and validation is explicit. Reading flow: Consistent formatting and logical method ordering help, but readers must repeatedly trace single-letter identifiers and helper calls to understand delegation and varargs handling.