Source code
package org.apache.kafka.common.utils;
import java.time.Duration;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
import java.util.function.Supplier;
public interface Time {
Time SYSTEM = SystemTime.getSystemTime();
long milliseconds();
default long hiResClockMs() {
return TimeUnit.NANOSECONDS.toMillis(nanoseconds());
}
long nanoseconds();
void sleep(long ms);
default void waitObject(Object obj, Supplier<Boolean> condition, long deadlineMs) throws InterruptedException {
synchronized (obj) {
while (true) {
if (condition.get())
return;
long currentTimeMs = milliseconds();
if (currentTimeMs >= deadlineMs)
throw new org.apache.kafka.common.errors.TimeoutException("Condition not satisfied before deadline");
obj.wait(deadlineMs - currentTimeMs);
}
}
}
default Timer timer(long timeoutMs) {
return new Timer(this, timeoutMs);
}
default Timer timer(Duration timeout) {
return timer(timeout.toMillis());
}
default <T> T waitForFuture(
Future<T> future,
long deadlineNs
) throws TimeoutException, InterruptedException, ExecutionException {
TimeoutException timeoutException = null;
while (true) {
long nowNs = nanoseconds();
if (deadlineNs <= nowNs) {
throw (timeoutException == null) ? new TimeoutException() : timeoutException;
}
long deltaNs = deadlineNs - nowNs;
try {
return future.get(deltaNs, TimeUnit.NANOSECONDS);
} catch (TimeoutException t) {
timeoutException = t;
}
}
}
}
Run 1
The code is generally well-structured with clear method separation and logical organization. It uses a flat hierarchy with minimal nesting except for one level in waitObject and waitForFuture. Intent is clear for most methods, with descriptive names and appropriate parameter types. However, there are excessive blank lines and comment placeholders that detract from readability. The waitForFuture method has slightly convoluted logic with the timeoutException variable and doubled timeout handling, making it less immediately clear. Action granularity is mostly good—one action per line—though some lines combine checks and throws. Reading flow is natural, but the many empty comments and inconsistent spacing interrupt it. Overall, it's readable but could be tightened by removing placeholder comments and simplifying waitForFuture's exception handling.
Run 2
The code is highly readable. Structure is logical: interface constants, core methods (milliseconds, nanoseconds, sleep), then well-organized default helper methods. Nesting is minimal—only one synchronized block and one while loop with clear exit conditions. Intent is clear from descriptive method names like waitObject, timer, and waitForFuture. Code length is concise with no redundant logic. Action granularity is appropriate: most lines perform a single logical operation, such as checking conditions, calculating time deltas, or waiting. Reading flow is natural, with helper methods following core abstractions. Minor drawbacks include some unnecessary vertical whitespace and a fully qualified TimeoutException reference in waitObject, which slightly interrupt flow but do not significantly hurt clarity.
Run 3
The code is generally readable and well-structured, with clear method names and logical organization within the Time interface. The use of default methods and overloaded timer() is sensible. However, several factors reduce readability: excessive blank lines and scattered comment placeholders disrupt the reading flow. The waitForFuture method uses a loop with repeated timeout handling that is somewhat harder to follow than necessary. waitObject mixes a condition check, time comparison, and object.wait in a compact block. While nesting is shallow and actions are mostly one per line, the presence of many empty comment sections and inconsistent spacing harms overall clarity and conciseness.
Run 1
Code Structure: The interface logically groups clock access, sleeping, timers, and waiting utilities. Nesting: Most methods are flat; waitObject and waitForFuture introduce moderate, manageable nesting. Clarity of intent: Descriptive method names and explicit time-unit suffixes make the purpose clear, although the future timeout retry behavior is not explained. Code length: Implementations are concise, but excessive blank lines unnecessarily lengthen the file. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Method ordering is natural, but inconsistent formatting, omitted braces on some conditionals, and the fully qualified exception name interrupt an otherwise straightforward flow.
Run 2
Code Structure: The interface logically groups clock access, sleeping, timers, and waiting helpers into small methods. Nesting: Generally shallow, although waitObject combines synchronization, a loop, and conditional checks; early exits keep it manageable. Clarity of intent: Descriptive method names and explicit time-unit suffixes make most behavior clear, but the retry loop and retained timeout exception in waitForFuture would benefit from explanation. Code length: Implementations are concise, but excessive blank lines unnecessarily lengthen the file. Action granularity: Statements generally perform one action per line; the conditional throw expression is slightly denser. Reading flow: Methods follow a sensible progression, but inconsistent spacing, excessive whitespace, and unbraced conditionals interrupt an otherwise straightforward reading experience.
Run 3
Code Structure: The interface logically groups clock access, sleeping, timer creation, and waiting utilities into small methods. Nesting: Most methods are flat; waitObject and waitForFuture have moderate, manageable nesting. Clarity of intent: Descriptive method names and explicit time units clarify purpose, though the distinction between clock sources and the future timeout retry behavior lack explanation. Code length: Implementations are concise, but excessive blank lines unnecessarily inflate the listing. Action granularity: Statements generally perform one action per line; the conditional throw expression is slightly denser. Reading flow: Methods follow a sensible progression, but inconsistent spacing, the multiline parameter layout, and unbraced conditionals mildly disrupt readability.