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 cache2, KeyGenerator tar) {
Assert.notNull(cache2, "JCacheOperationSource must not be null");
Assert.notNull(tar, "KeyGenerator must not be null");
this.cacheOperationSource = cache2;
this.keyGenerator = tar;
}
/**
* Create an instance used to wrap the specified {@link javax.cache.annotation.CacheKeyGenerator}.
*/
public KeyGeneratorAdapter(JCacheOperationSource cache3, CacheKeyGenerator tar2) {
Assert.notNull(cache3, "JCacheOperationSource must not be null");
Assert.notNull(tar2, "CacheKeyGenerator must not be null");
this.cacheOperationSource = cache3;
this.cacheKeyGenerator = tar2;
}
/**
* Return the target key generator to use in the form of either a {@link KeyGenerator}
* or a {@link CacheKeyGenerator}.
*/
public Object get() {
if (this.cacheKeyGenerator != null) {
return this.cacheKeyGenerator;
}
Assert.state(this.keyGenerator != null, "No key generator");
return this.keyGenerator;
}
@Override
public Object gen(Object tar3, Method met, @Nullable Object... par) {
JCacheOperation<?> ope = this.cacheOperationSource.getCacheOperation(met, tar3.getClass());
if (!(ope instanceof AbstractJCacheKeyOperation)) {
throw new IllegalStateException("Invalid operation, should be a key-based operation " + ope);
}
CacheKeyInvocationContext<?> invocation = create(tar3, ope, par);
if (this.cacheKeyGenerator != null) {
return this.cacheKeyGenerator.generateCacheKey(invocation);
}
else {
Assert.state(this.keyGenerator != null, "No key generator");
return do2(this.keyGenerator, invocation);
}
}
private static Object do2(KeyGenerator key, CacheKeyInvocationContext<?> con) {
List<Object> par2 = new ArrayList<>();
for (CacheInvocationParameter par3 : con.getKeyParameters()) {
Object val = par3.getValue();
if (par3.getParameterPosition() == con.getAllParameters().length - 1 &&
con.getMethod().isVarArgs()) {
par2.addAll(CollectionUtils.arrayToList(val));
}
else {
par2.add(val);
}
}
return key.generate(con.getTarget(), con.getMethod(), par2.toArray());
}
@SuppressWarnings("unchecked")
private CacheKeyInvocationContext<?> create(
Object tar4, JCacheOperation<?> ope2, @Nullable Object[] par4) {
AbstractJCacheKeyOperation<Annotation> key2 = (AbstractJCacheKeyOperation<Annotation>) ope2;
return new DefaultCacheKeyInvocationContext<>(key2, tar4, par4);
}
}
Run 1
The code has a clear purpose but suffers from poor readability due to cryptic variable names (tar, tar2, met, par, ope), abbreviated method names (gen, do2, create), and inconsistent parameter naming (cache2, cache3, par2, par3). These obscure intent despite logical class structure and documentation. The code is relatively flat with simple nesting, but the generics and casts harm clarity. Action granularity is mostly acceptable, yet parameter lists are long. The adaptation logic between Spring and JCache APIs is not immediately obvious. Overall, the code functions but requires extra effort to understand, making it less readable.
Run 2
The code has significant readability issues. Method names like 'gen', 'do2', 'tar', 'tar3', 'par2', 'par3', 'ope2', 'tar4', 'par4', and 'cache2', 'cache3' are cryptic and fail to convey intent. The constructor parameters are inconsistently named (cache2/tar, cache3/tar2). The 'do2' method has moderate nesting and unclear logic regarding varargs handling. While the class structure is logical, the get() method mixes two different delegate types into an Object return, obscuring intent. The code has reasonable length and one action per line, but the terrible naming destroys clarity. Reading flow is disrupted by having to mentally map numbered variables to their meaning. The structure is acceptable but execution falls far short of the Spring framework's usual readability standards.
Run 3
The code is difficult to read due to poor naming conventions (e.g., cache2, tar, tar2, par, par2, ope2, do2, gen) that obscure intent. The structure is tangled: the class mixes adapter logic, method logic, and helper methods without clear separation of concerns. The use of two constructors with nearly identical parameter types but different meanings adds confusion. Nesting is moderate but the reading flow is disrupted by ambiguous variable names and unclear method purposes. Action granularity is acceptable, but the method names and parameters make it hard to follow the logic. Concise but not self-documenting; the comments are helpful but don't compensate for poor naming and structure.
Run 1
Code Structure: The class is logically organized into constructors, delegation methods, parameter handling, and context creation, with well-separated responsibilities. Nesting: Mostly shallow; the loop with an internal conditional is easy to follow. Clarity of intent: Documentation and descriptive type names explain the adapter's purpose, but names such as gen, do2, tar3, ope2, and par4 obscure individual operations and data roles. Code length: Reasonably concise, with little unnecessary implementation detail; constructor duplication is understandable for different generator types. Action granularity: Statements generally perform one action per line, although some expressions combine several method calls. Reading flow: Consistent formatting and straightforward control flow help, but cryptic names require repeated cross-referencing. Additionally, gen marked @Override appears inconsistent with KeyGenerator's generate method, creating confusion about the intended interface implementation.
Run 2
Code Structure: The adapter is logically divided into constructors, delegation, parameter processing, and context creation. Nesting: Mostly shallow, with only a loop containing an if/else. Clarity of intent: Documentation and descriptive type names explain the overall purpose, but names such as gen, do2, tar3, ope2, and par4 obscure individual operations. Code length: Reasonably concise, although repeated constructor validation and verbose documentation add some length. Action granularity: Statements generally perform one action per line; the compound varargs condition remains manageable. Reading flow: Method ordering and consistent formatting support sequential reading, but cryptic identifiers force readers to repeatedly infer roles. Additionally, gen appears inconsistent with the KeyGenerator interface's generate method, making the override confusing.
Run 3
Code Structure: The adapter is logically divided into constructors, generator selection, delegation, parameter handling, and context creation. Nesting: Mostly shallow, with only a loop containing an if/else. Clarity of intent: Documentation and descriptive type names explain the purpose, but cryptic identifiers such as tar3, ope2, par4, do2, and gen substantially obscure behavior. Code length: Reasonably concise, with limited duplication in constructor validation. Action granularity: Statements generally perform one action per line; the multiline condition remains understandable. Reading flow: Method ordering and consistent formatting support sequential reading, but numbered variable names and vague helper names force readers to infer meaning repeatedly. The gen method's @Override also appears inconsistent with KeyGenerator's generate method, creating additional confusion.