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() {}
/**
* 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> a(
RemovalListener<K, V> a, Executor b) {
checkNotNull(a);
checkNotNull(b);
return (RemovalNotification<K, V> c) ->
b.execute(() -> a.onRemoval(c));
}
}
Run 1
The code is functionally clear but uses placeholder parameter names (a, b, c) that obscure intent, significantly reducing readability. Structure is logical, concise, and flat with minimal nesting. However, the action granularity and reading flow suffer due to unclear naming, making it harder to follow despite the code being short. Javadocs are helpful but cannot compensate for poor nomenclature.
Run 2
The code is generally well-structured with clear separation of concerns, a private constructor preventing instantiation, and appropriate Javadoc. However, readability is significantly hurt by poor parameter naming ('a', 'b', 'c') which obscures intent and forces the reader to rely on documentation. The nesting is minimal (one lambda inside another), and each action has its own line, but the generic type parameter '<K, V>' combined with the lambda syntax adds mild complexity. The reading flow suffers from the unnamed descriptive variables. Overall the structure is clean and concise but naming choices reduce clarity.
Run 3
The code has a clean structure with clear separation of concerns, proper null checks, and simple lambda composition. It follows good practices like a private constructor and Javadoc documentation. However, readability is significantly hurt by poor naming: the method is called 'a', and parameters are 'a', 'b', and 'c', which obscures intent and forces the reader to infer meaning from types. The reading flow is straightforward but generic names break clarity. Action granularity and nesting are acceptable—each lambda does one thing and indentation is shallow. The overall code is concise, but sacrificing descriptive names for brevity is a trade-off that reduces readability. With meaningful names (e.g., 'asynchronous' and 'listener'), this would be highly readable.
Run 1
Code Structure: A well-organized utility class with a private constructor and one focused factory method. Nesting: Minimal nesting; the two lambdas are compact and easy to follow. Clarity of intent: Class documentation and types explain asynchronous removal handling, but names a, b, and c obscure roles, and the documented parameter names do not match the implementation. Code length: Concise, with no unnecessary logic. Action granularity: Null checks occupy separate lines, and the return expression performs one cohesive operation. Reading flow: Validation followed by listener creation is natural, although cryptic identifiers and tightly grouped imports slightly impede readability.
Run 2
Code Structure: Well-organized utility class with a private constructor and one focused factory method. Nesting: Minimal; the nested lambdas are compact and easy to follow. Clarity of intent: Class documentation and API types explain the asynchronous listener wrapper, but single-letter method and parameter names obscure intent. The documented parameter names also mismatch the actual names. Code length: Concise, with no unnecessary implementation detail. Action granularity: Validation calls each occupy their own line, and the lambda clearly expresses scheduling a callback. Reading flow: Natural progression from input validation to wrapper creation, though cryptic identifiers and tight import spacing slightly reduce readability.
Run 3
Code Structure: A logically organized utility class with a private constructor and one focused factory method. Nesting: Minimal; the nested lambdas are shallow and manageable. Clarity of intent: Documentation explains asynchronous notification handling, but the method name 'a' and variable names 'a', 'b', and 'c' obscure their roles. Code length: Concise, with no unnecessary implementation. Action granularity: Null checks are separate statements, and the returned expression cleanly encapsulates task scheduling. Reading flow: Straightforward from validation to listener creation, although cryptic identifiers and tightly grouped package/import declarations reduce readability.