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;
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 timeoutMs, List<CompletableFuture<T>> futures, Runnable responseCallback) {
super(timeoutMs);
this.timeoutMs = timeoutMs;
this.futures = futures;
this.responseCallback = responseCallback;
}
@Override
public boolean tryComplete() {
log.trace("Trying to complete operation for {} futures", futures.size());
long pending = futures.stream().filter(future -> !future.isDone()).count();
if (pending == 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", pending);
return false;
}
}
@Override
public void onComplete() {
List<CompletableFuture<T>> pendingFutures = futures.stream().filter(future -> !future.isDone()).toList();
log.trace("Completing operation for {} futures, expired {}", futures.size(), pendingFutures.size());
pendingFutures.forEach(future -> future.completeExceptionally(new TimeoutException("Request has been timed out after " + timeoutMs + " ms")));
responseCallback.run();
}
@Override
public void onExpiration() {
}
}
Run 1
The code is well-structured, flat, and concise. It clearly expresses intent through meaningful names and focused methods. Each method performs a single action per line, with no deep nesting. Minor deductions: unused imports, excessive blank lines, an empty method that could be clarified with a comment, and duplicated timeoutMs field that could be inherited.
Run 2
The code is generally readable with clear class purpose and good method separation. It uses descriptive names and logging effectively. The implementation is concise with minimal nesting. However, there are minor issues: the onExpiration method is empty with no explanation, the onComplete method name is slightly misleading since it handles pending futures on expiration, and there are some unnecessary blank lines. The tryComplete and onComplete methods have clear logic, but the distinction between them could be clearer. The code could benefit from a comment explaining the relationship between onComplete and onExpiration in the DelayedOperation lifecycle.
Run 3
The code is well-structured with clear separation of concerns and follows a logical organization. It maintains a flat structure with minimal nesting, making the control flow easy to follow. The intent is clear - this class manages delayed operations tied to CompletableFutures. Methods are concise and focused with good action granularity, typically one clear action per line. The reading flow is natural and progressive. Minor deductions: the empty onExpiration() method creates slight ambiguity about the intended behavior, multiple blank lines before methods add unnecessary spacing, and variable names like 'pending' shadow the method context slightly. The code could benefit from a brief class-level javadoc explaining the relationship between futures, timeout, and callback. Overall strong readability with clear naming conventions and appropriate logging that aids debugging.
Run 1
Code Structure: Fields, constructor, and lifecycle overrides are logically organized, although excessive blank lines add visual clutter. Nesting: Shallow nesting makes control flow easy to follow; the else after an early return is unnecessary. Clarity of intent: Descriptive names and logging clearly communicate completion and timeout handling, but the empty onExpiration method lacks an explanation. Code length: The implementation is concise overall, though whitespace and long stream/lambda lines reduce scanability. Action granularity: Statements generally perform one action per line; the exceptional-completion lambda combines exception construction and completion in one lengthy expression. Reading flow: The progression from initialization to completion checking and finalization is natural, with minor disruption from inconsistent spacing and dense expressions.
Run 2
Code Structure: Fields, constructor, and lifecycle methods are logically organized. Nesting: Very shallow, with only one simple if/else branch. Clarity of intent: Descriptive names and trace messages clearly communicate completion and timeout handling, although the empty onExpiration method lacks an explanation. Code length: Concise overall, but excessive blank lines add visual clutter and the else after a return is unnecessary. Action granularity: Statements generally perform one action per line; the long completeExceptionally lambda combines construction and completion, making it slightly harder to scan. Reading flow: Natural progression from initialization to completion checks and callbacks, with inconsistent whitespace and long stream expressions slightly interrupting readability.
Run 3
Code Structure: Fields, constructor, and lifecycle methods are logically organized with clear responsibilities. Nesting: Control flow is shallow, with only a simple if/else branch. Clarity of intent: Descriptive names and logging clarify completion and timeout handling, although the empty onExpiration method lacks an explanation. Code length: The implementation is concise, but excessive blank lines add visual clutter and the else after an early return is unnecessary. Action granularity: Statements generally perform one action each; stream operations are cohesive, though the long exceptional-completion lambda is harder to scan. Reading flow: The progression from initialization to completion checks and callback execution is natural. Inconsistent whitespace, long lines, and unexplained lifecycle behavior slightly reduce readability.