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> removeBuffer(
RemovalListener<K, V> category, Executor document) {
checkNotNull(category);
checkNotNull(document);
return (RemovalNotification<K, V> sharedBuffer) ->
document.execute(() -> category.onRemoval(sharedBuffer));
}
}
Run 1
The code is generally well-structured with a clear single-purpose class. It uses static imports appropriately and has a private constructor to prevent instantiation. The method has a single level of nesting and the lambda expression is concise. However, the parameter names `category`, `document`, and `sharedBuffer` are misleading - they suggest document categories rather than the actual removal listener and executor components. This significantly reduces readability and clarity of intent. The method name `removeBuffer` is also vague about its purpose of wrapping a listener with async execution. The reading flow is natural, and action granularity is good with one action per line, but the contradictory naming creates confusion.
Run 2
The code is well-structured and readable. It has a clear class purpose, minimal nesting, and concise methods. The naming inconsistency (e.g., 'removeBuffer', 'category', 'document' instead of expected 'asynchronous', 'listener', 'executor') slightly hurts clarity but does not obscure intent. The action granularity is good: validation and return are separate lines. The reading flow is natural and the documentation is helpful. Minor verbosity exists in the Javadoc but is appropriate for library code.
Run 3
The code is generally readable with a clear logical structure. The class has a single responsibility and the method is concise. However, the parameter and variable names ('category', 'document', 'sharedBuffer') are misleading and do not reflect their actual purpose (listener, executor, notification). This hurts clarity of intent. Nesting is minimal and the reading flow is natural, but the action granularity is slightly compressed in the lambda expression. The code is not excessively long or tangled, but renaming variables would significantly improve comprehension.
Run 1
Code Structure: A small, logically organized utility class with a private constructor and one factory method. Nesting: Minimal; the nested lambdas are compact and easy to follow. Clarity of intent: The asynchronous listener behavior is understandable, but misleading names such as removeBuffer, category, document, and sharedBuffer obscure roles. Javadoc parameter names also do not match the actual parameters. Code length: Concise, with no unnecessary implementation detail. Action granularity: Null checks occupy separate lines, and the return expression represents one cohesive operation. Reading flow: Generally natural, progressing from validation to listener construction, though naming inconsistencies and missing spacing between package and imports reduce polish.
Run 2
Code Structure: A well-organized utility class with a private constructor and one focused factory method. Nesting: Shallow; the nested lambdas remain easy to follow. Clarity of intent: Documentation explains asynchronous notification handling, but removeBuffer, category, document, and sharedBuffer are misleading names. The Javadoc parameter names also do not match the actual parameters. Code length: Concise, with no unnecessary implementation code. Action granularity: Null checks are separate statements, and the lambda expression cleanly represents scheduling the callback. Reading flow: Mostly natural, progressing from validation to listener construction, though inconsistent naming and tightly grouped package/import declarations reduce readability.
Run 3
Code Structure: A well-organized utility class with a private constructor and one focused method. Nesting: Shallow; the nested lambdas are compact and easy to follow. Clarity of intent: The implementation clearly delegates removal notifications to an executor, but removeBuffer, category, document, and sharedBuffer are misleading names. Javadoc references listener and executor rather than the actual parameter names, further reducing clarity. Code length: Concise, with no unnecessary implementation code. Action granularity: Null checks occupy separate lines, and the lambda expresses a single scheduling operation. Reading flow: The progression from validation to asynchronous delegation is natural, although inconsistent naming and tightly grouped package/import declarations interrupt readability.