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> asy(
RemovalListener<K, V> lis, Executor exe) {
checkNotNull(lis);
checkNotNull(exe);
return (RemovalNotification<K, V> not) ->
exe.execute(() -> lis.onRemoval(not));
}
}
Run 1
The code is generally well-structured with clear intent and good readability. The class has a clear single purpose, uses appropriate annotations, and includes helpful Javadoc. However, readability is reduced by abbreviated parameter names ('asy', 'lis', 'exe', 'not'), which force the reader to rely on the documentation rather than the code itself. The method name 'asy' is ambiguous without context. Nesting is minimal and the logic flows naturally. The code is concise with one action per line. Overall, it is readable but would benefit from more descriptive naming.
Run 2
The code is generally readable but has some minor issues. The structure is logical with clear separation between the class, constructor, and static method. Nesting is flat, which is good. Intent is mostly clear through the Javadoc and method name, though the abbreviated parameter names ('asy', 'lis', 'exe') reduce clarity slightly. Code length is concise, though the method name 'asy' is overly terse. Action granularity is appropriate, with one main action per line. Reading flow is natural, moving from validation to returning the listener. The main deductions are for overly abbreviated names which sacrifice clarity for brevity, and the method name 'asy' which is ambiguous without reading the documentation. Overall, it is well-structured and readable but could be improved with more descriptive naming.
Run 3
The code is generally well-structured and readable, with a clear single-purpose class and appropriate use of static factory method and lambda expressions. The class has a logical organization with Javadoc explaining intent, and the method performs two validation checks followed by a concise lambda expression. However, the parameter names are abbreviated ('asy', 'lis', 'exe', 'not'), which slightly reduces clarity of intent compared to more descriptive names like 'asynchronous', 'listener', 'executor', and 'notification'. The method name 'asy' is ambiguous at first glance. Nesting is minimal, and the reading flow is natural. Action granularity is appropriate—one action per line. The code length is concise without being overly terse. With more descriptive naming, it would be nearly perfect.
Run 1
Code Structure: A well-organized utility class with a private constructor and one focused public method. Nesting: Minimal; the nested lambdas are compact and easy to follow. Clarity of intent: Documentation explains asynchronous notification handling, but abbreviated identifiers such as asy, lis, exe, and not obscure meaning. The documentation also uses parameter names that do not match the signature. Code length: Concise, with no unnecessary implementation details. Action granularity: Null checks appear on separate lines, and the return expression performs one cohesive operation. Reading flow: Validation naturally precedes listener construction, though missing spacing around imports and abbreviated names slightly hinder readability.
Run 2
Code Structure: A logically organized utility class with a private constructor and one focused factory method. Nesting: Minimal; the nested lambdas are shallow and easy to follow. Clarity of intent: Documentation explains asynchronous notification delivery, but abbreviated names such as asy, lis, exe, and not reduce clarity. The documented parameter names also differ from the actual names. Code length: Concise, with no unnecessary implementation code. Action granularity: Each validation occupies its own line, and the return expression cleanly encapsulates delegation. Reading flow: Validation naturally precedes listener creation, although missing spacing between the package and imports and the abbreviations slightly hinder scanning.
Run 3
Code Structure: A well-organized utility class contains one focused factory method and a private constructor. Nesting: Minimal; the nested lambdas are shallow and easy to follow. Clarity of intent: Documentation and null checks clarify the asynchronous listener wrapper, but abbreviated names (asy, lis, exe, not) reduce clarity, and documented parameter names do not match the actual parameters. Code length: Concise without unnecessary implementation detail. Action granularity: Each validation occupies its own line, and the return expression expresses one cohesive operation. Reading flow: Execution proceeds naturally from validation to wrapper creation, though missing spacing between the package declaration and imports slightly weakens presentation.