Source code
package org.apache.kafka.server.purgatory;
import org.apache.kafka.common.errors.TimeoutException;
import org.apache.kafka.common.utils.internals.LogContext;
import org.slf4j.Logger;
import java.util.List;
import java.util.concurrent.CompletableFuture;
/**
* A delayed operation using CompletionFutures that can be created by KafkaApis and watched
* in a DelayedFuturePurgatory purgatory. This is used for ACL updates using async Authorizers.
*/
public class DelayedFuture<T> extends DelayedOperation {
private final Logger log = new LogContext().logger(DelayedFuture.class.getName());
private final List<CompletableFuture<T>> futures;
private final Runnable responseCallback;
private final long timeoutMs;
public DelayedFuture(long a, List<CompletableFuture<T>> b, Runnable c) {
super(a);
this.timeoutMs = a;
this.futures = b;
this.responseCallback = c;
}
/**
* The operation can be completed if all the futures have completed successfully
* or failed with exceptions.
*/
@Override
public boolean a() {
log.trace("Trying to complete operation for {} futures", futures.size());
long d = futures.stream().filter(future -> !future.isDone()).count();
if (d == 0) {
log.trace("All futures have been completed or have errors, completing the delayed operation");
return forceComplete();
} else {
log.trace("{} future still pending, not completing the delayed operation", d);
return false;
}
}
/**
* Timeout any pending futures and invoke responseCallback. This is invoked when all
* futures have completed or the operation has timed out.
*/
@Override
public void b() {
List<CompletableFuture<T>> e = futures.stream().filter(future -> !future.isDone()).toList();
log.trace("Completing operation for {} futures, expired {}", futures.size(), e.size());
e.forEach(future -> future.completeExceptionally(new TimeoutException("Request has been timed out after " + timeoutMs + " ms")));
responseCallback.run();
}
/**
* This is invoked after onComplete(), so no actions required.
*/
@Override
public void c() {
// This is invoked after onComplete(), so no actions required.
}
}
Run 1
The code is heavily obfuscated and unreadable. Meaningful names like 'DelayedFuture', 'futures', 'responseCallback', and 'timeoutMs' have been replaced with single letters ('a', 'b', 'c', 'd', 'e'), making the logic and intent highly ambiguous. Method names such as 'a()', 'b()', and 'c()' provide no indication of their behavior (checking completion, handling timeout, or post-completion actions). While the structure is flat and the logic itself is not deeply nested, the loss of semantic naming destroys clarity of intent and reading flow. The class-level Javadoc provides some context, but it is insufficient to compensate for the cryptic identifiers throughout the implementation. The code remains concise in terms of length, but the severe obfuscation of all identifiers warrants a very low readability score.
Run 2
The code suffers from severe readability issues. Methods and parameters use meaningless single-letter names (a, b, c, d, e) that completely obscure intent, making the code impossible to follow without guessing. The class inherits from DelayedOperation but the overridden methods have been renamed to 'a()', 'b()', and 'c()', hiding their lifecycle purpose. The 'forceComplete()' call and 'responseCallback' usage are contextually unclear. Additionally, variable names like 'd' represent counts but give no indication of meaning. While structure and nesting are relatively flat, the lack of semantic naming destroys clarity, violates action granularity through vague collections, and makes the reading flow disorganized. The code length is reasonable, but it doesn't compensate for the semantic ambiguity. This is effectively obfuscated code that would require significant mental effort or external documentation to understand.
Run 3
The code's structure is logical but severely undermined by obfuscated naming: parameters like 'a', 'b', 'c', methods 'a()', 'b()', 'c()', and variables 'd', 'e' render the intent opaque. Nesting is acceptable and action granularity is reasonable, yet the cryptic identifiers force readers to infer meaning from comments rather than the code itself. While concise, the abbreviations create ambiguity and disrupt natural reading flow, making the class difficult to understand without external documentation. Clear method names (e.g., tryComplete(), onComplete(), onExpiration()) and meaningful variables would drastically improve clarity.
Run 1
Code Structure: Fields, constructor, and lifecycle methods are logically organized, with responsibilities separated. Nesting: Shallow control flow and simple stream operations make the code easy to follow. Clarity of intent: Descriptive fields, documentation, and logging explain the behavior, but methods a(), b(), c() and variables a–e obscure meaning; the onComplete() reference also does not match the displayed method names. Code length: Compact overall, though the else after a return and repeated comment in c() are unnecessary. Action granularity: Most statements perform one action, but the long forEach lambda combines filtering results, timeout construction, and exceptional completion conceptually across adjacent statements. Reading flow: Execution proceeds naturally from completion checking to timeout handling and callback invocation, but cryptic identifiers and long stream/lambda lines interrupt readability.
Run 2
Code Structure: Fields, constructor, and lifecycle methods are logically organized with focused responsibilities. Nesting: Shallow control flow, with only one if/else and simple stream lambdas, makes the code easy to follow. Clarity of intent: Descriptive fields, logging, and Javadoc explain the operation, but method names a(), b(), c() and variables a–e obscure meaning. The onComplete() reference also does not match the visible method names. Code length: Mostly concise, although the empty method repeats its documentation and the else could be omitted after the return. Action granularity: Statements generally perform one action per line; the long exceptional-completion lambda combines filtering context, exception construction, and completion into a visually dense statement. Reading flow: The sequence from initialization to completion checking, timeout handling, and the empty expiration hook is natural, but cryptic identifiers and long lines interrupt comprehension.
Run 3
Code Structure: Fields, constructor, and lifecycle methods are logically organized, with completion checking separated from timeout handling. Nesting: Shallow nesting and simple stream operations make control flow easy to follow. Clarity of intent: Descriptive fields, logging, and documentation explain the purpose, but method names a(), b(), c(), constructor parameters a/b/c, and local variables d/e significantly obscure meaning. The onComplete() reference does not match the visible method names. Code length: Compact and mostly appropriate, though the empty method repeats its documentation in a comment. Action granularity: Statements generally perform one action per line; the long exceptional-completion lambda combines filtering-independent iteration, exception construction, and completion into a dense expression. Reading flow: The progression from initialization to completion checking and cleanup is natural, but cryptic identifiers and long stream/lambda lines interrupt readability.