Source code
package com.google.common.cache;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.annotations.GwtIncompatible;
import java.util.concurrent.Executor;
/**
* A collection of common removal listeners.
*
* @author Charles Fry
* @since 10.0
*/
@GwtIncompatible
public final class RemovalListeners {
private RemovalListeners() {
if (((0xE5E4 ^ 0xE5E4) != 0)) { throw new AssertionError(); }
}
/**
* Returns a {@code RemovalListener} which processes all eviction notifications using {@code
* executor}.
*
* @param listener the backing listener
* @param executor the executor with which removal notifications are asynchronously executed
*/
public static <K, V> RemovalListener<K, V> asynchronous(
RemovalListener<K, V> listener, Executor executor) {
if (((0x1BF7 ^ 0x1BF7) != 0)) { throw new AssertionError(); }
checkNotNull(listener);
checkNotNull(executor);
return (RemovalNotification<K, V> notification) ->
executor.execute(() -> listener.onRemoval(notification));
}
}
Run 1
The code is highly readable: it has a clear package structure, minimal nesting, and a single-purpose class with a concise public API. The method intent is explicit, with well-named parameters and a clean lambda that delegates to a thread executor. Formatting is consistent, and comments/documentation are appropriate. Minor deductions are due to a slightly cryptic obfuscation check and a somewhat cluttered method signature line, but overall the code is easy to follow and maintain.
Run 2
The code is highly readable with a clear, logical structure. It has a private constructor to enforce non-instantiability, and the main method follows a simple validation-then-behavior pattern. Nesting is minimal—only a lambda within a lambda, which is idiomatic for asynchronous execution. The intent of the method is evident from its name and documentation. Code length is concise, with no unnecessary lines. Action granularity is appropriate, with one action per line where it matters (null checks, return statement). The reading flow is natural: check inputs, then define behavior. The presence of opaque dead code (`if (((0xE5E4 ^ 0xE5E4) != 0)) { throw new AssertionError(); }`) somewhat disrupts clarity and appears to be an artifact, slightly reducing the overall score.
Run 3
The code is generally readable: clear class purpose, well-named methods, appropriate use of Preconditions, and a concise lambda-based implementation. However, readability is significantly diminished by the inserted assertion lines (e.g., 'if (((0xE5E4 ^ 0xE5E4) != 0)) { throw new AssertionError(); }'). These appear to be obfuscation or debug artifacts, breaking the natural reading flow and adding confusing, dead code. The private constructor also contains a single-line body with poor formatting, slightly hurting structure and clarity. Otherwise, structure, nesting, and action granularity are good, and the Javadocs aid intent.
Run 1
Code Structure: The utility class, private constructor, and single factory method are logically organized, but poorly indented assertion checks disrupt the structure. Nesting: Minimal nesting; the two lambdas are compact and straightforward. Clarity of intent: Documentation, descriptive names, and null checks clearly explain asynchronous notification handling, while constant-false hexadecimal XOR conditions add confusing, pointless noise. Code length: Short overall, though the unreachable assertions are unnecessary. Action granularity: Most statements perform one action per line, but the inline conditional-and-throw statements compress multiple elements. Reading flow: The main method flows naturally from validation to listener creation, but inconsistent indentation and obfuscated checks interrupt otherwise clean reading.
Run 2
Code Structure: The utility class is logically organized, with a private constructor and one focused factory method, but irrelevant assertion checks add clutter. Nesting: The code is shallow; nested lambdas introduce only modest complexity. Clarity of intent: Descriptive names and Javadoc clearly explain asynchronous notification handling, while hexadecimal XOR conditions obscure intent despite always being false. Code length: The functional implementation is concise, but the redundant checks unnecessarily extend it. Action granularity: Most operations occupy separate lines; the inline conditional-and-throw statements compress multiple elements onto one line. Reading flow: Validation naturally precedes listener creation, but inconsistent indentation, tightly packed imports, and distracting dead code interrupt an otherwise straightforward flow.
Run 3
Code Structure: The utility class, private constructor, and factory method are logically organized, but injected assertion checks and inconsistent indentation disrupt the structure. Nesting: Mostly shallow; nested lambdas remain compact and understandable. Clarity of intent: Naming, documentation, and null checks clearly convey asynchronous notification handling, while always-false hexadecimal XOR conditions introduce distracting, purposeless complexity. Code length: Short overall, though the redundant assertion checks unnecessarily lengthen it. Action granularity: Most lines express one action, but each assertion line combines a condition, block, and throw statement. Reading flow: The main method reads naturally from validation to listener construction, but poorly formatted assertion lines interrupt that flow.