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() {
{int lI0O_41a6abf5=(0xF35D^0xF35D);switch(lI0O_41a6abf5){case 0:lI0O_41a6abf5|=0;break;default:lI0O_41a6abf5&=0;}}
}
/**
* 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) {
checkNotNull(listener);
checkNotNull(executor);
return (RemovalNotification<K, V> notification) ->
executor.execute(() -> listener.onRemoval(notification));
}
}
Run 1
The code is generally clean and well-structured, with a single static factory method and clear purpose. The use of preconditions and lambda expressions makes the asynchronous listener implementation concise. However, a significant readability issue is the presence of a dead code block inside the private constructor containing an obfuscated variable and switch statement. This artifact severely detracts from the code's clarity and likely indicates accidental corruption or mocking. The constructor should simply be empty. The Javadoc and method signature are clear, and the lambda body is easily understood. The flow from validation to returning the listener is natural. Removing the dead code would elevate the overall readability.
Run 2
The code has a clear overall structure with a private constructor and a single factory method, and the import section is minimal. However, readability is significantly degraded by the obfuscated dead code inserted into the constructor — an unexplained dummy switch statement with opaque variable names and bitwise operations. This breaks several criteria: clarity of intent is severely damaged, reading flow is disrupted, and unnecessary code length is introduced. The asynchronous method itself is concise and uses a lambda cleanly, demonstrating good action granularity and flat nesting, but the constructor artifact undermines the whole file. Removing that block would raise this to roughly 17–18, but as written it appears intentionally misleading or the result of code pollution.
Run 3
The code has clear intent and logical structure, with a single purposeful method and good use of lambdas. However, readability is undermined by the obfuscated dead code injected into the constructor—an arbitrary switch statement with a cryptic variable name and zero effect. This violates clarity of intent, adds unnecessary length, and disrupts reading flow. Aside from this, the code is well-named, flat, and concise, but the presence of confusing, irrelevant code significantly detracts from overall readability.
Run 1
Code Structure: The utility class, imports, documentation, and asynchronous factory are logically organized, but the constructor contains unrelated obfuscated code. Nesting: The factory is shallow and straightforward; the constructor adds unnecessary block and switch nesting. Clarity of intent: Documentation, descriptive names, null checks, and lambdas clearly communicate asynchronous notification dispatch, while the constructor's cryptic variable and no-op operations obscure its purpose. Code length: The functional implementation is concise, but the constructor adds needless code. Action granularity: Most statements occupy separate lines, whereas the constructor compresses declarations, branching, assignments, and breaks onto one line. Reading flow: The factory reads naturally from validation to listener creation, but inconsistent constructor formatting and dense irrelevant logic interrupt the overall flow.
Run 2
Code Structure: The utility class and asynchronous factory method are logically organized, but the constructor contains unrelated obfuscated code. Nesting: The main method is shallow; the constructor adds unnecessary block and switch nesting. Clarity of intent: Documentation, descriptive parameters, and the executor delegation clearly explain asynchronous notification handling, while the constructor's cryptic variable and no-op bitwise operations obscure intent. Code length: The functional implementation is concise, but the constructor adds needless complexity. Action granularity: Validation and delegation are cleanly separated, whereas the constructor compresses declarations, branching, assignments, and breaks onto one line. Reading flow: The documented method reads naturally, but inconsistent formatting and the dense constructor interrupt an otherwise straightforward flow.
Run 3
Code Structure: The utility class and asynchronous factory method are logically organized, but the constructor contains unrelated obfuscated code. Nesting: The main method is shallow; the constructor adds unnecessary block and switch nesting. Clarity of intent: Documentation, descriptive names, and null checks make asynchronous notification handling clear, while the constructor's cryptic variable and no-op bitwise operations obscure its purpose. Code length: The useful implementation is concise, but the constructor adds unnecessary code. Action granularity: The main method separates actions cleanly; the constructor compresses declarations, branching, assignments, and breaks into one line. Reading flow: The documented method reads naturally, but the poorly formatted constructor disrupts the flow and forces readers to decipher irrelevant logic.