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;
/**
* An interface abstracting the clock to use in unit testing classes that make use of clock time.
*
* Implementations of this class should be thread-safe.
*/
public interface Time {
Time SYSTEM = SystemTime.getSystemTime(); /**
* Returns the current time in milliseconds.
*/ long milliseconds();
/**
* Returns the value returned by `nanoseconds` converted into milliseconds.
*/ default long hiResClockMs() {
return TimeUnit.NANOSECONDS.toMillis(nanoseconds()); }
/**
* Returns the current value of the running JVM's high-resolution time source, in nanoseconds.
*
* <p>This method can only be used to measure elapsed time and is
* not related to any other notion of system or wall-clock time.
* The value returned represents nanoseconds since some fixed but
* arbitrary <i>origin</i> time (perhaps in the future, so values
* may be negative). The same origin is used by all invocations of
* this method in an instance of a Java virtual machine; other
* virtual machine instances are likely to use a different origin.
*/
long nanoseconds();
/**
* Sleep for the given number of milliseconds
*/
void sleep(long ms); /**
* Wait for a condition using the monitor of a given object. This avoids the implicit
* dependence on system time when calling {@link Object#wait()}.
*
* @param obj The object that will be waited with {@link Object#wait()}. Note that it is the responsibility
* of the caller to call notify on this object when the condition is satisfied.
* @param condition The condition we are awaiting
* @param deadlineMs The deadline timestamp at which to raise a timeout error
*
* @throws org.apache.kafka.common.errors.TimeoutException if the timeout expires before the condition is satisfied
*/
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); }
} }
/**
* Get a timer which is bound to this time instance and expires after the given timeout
*/ default Timer timer(long timeoutMs) {
return new Timer(this, timeoutMs);
} /**
* Get a timer which is bound to this time instance and expires after the given timeout
*/ default Timer timer(Duration timeout) { return timer(timeout.toMillis());
} /**
* Wait for a future to complete, or time out.
*
* @param future The future to wait for.
* @param deadlineNs The time in the future, in monotonic nanoseconds, to time out.
* @return The result of the future.
* @param <T> The type of the future.
*/
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 has severe readability issues. The package declaration and import statements are crammed onto one line, violating standard formatting. Multiple method definitions and comments are placed on the same line, making the structure confusing. The waitObject method contains deeply nested logic with while(true), if statements, and synchronized blocks all compressed together. Action granularity is poor - multiple actions appear on single lines throughout. The reading flow is disrupted by inconsistent spacing, misplaced comments, and methods that begin immediately after previous ones end. While individual method names and some Javadoc are clear, the overall presentation makes it difficult to follow the code's intent. The code appears to have lost all standard formatting, possibly through an automated process that removed line breaks. Proper indentation, line breaks between methods, and consistent spacing would significantly improve readability.
Run 2
The code has severe readability issues primarily due to formatting and structure. Multiple declarations, Javadocs, and method implementations are crammed onto single lines (e.g., Time SYSTEM, sleep(), waitObject(), timer(), etc.), violating action granularity and making parsing mentally taxing. Braces and control flow are inconsistently indented, leading to confusing nesting and reading flow. While method names and intent are generally clear, the presentation obscures the logic. The interface is not overly long but becomes hard to follow because of the compressed layout and mixed organization. Several methods are missing proper line breaks before annotations or closing braces. Overall, the code requires significant reformatting to be considered readable, despite the underlying logic being straightforward.
Run 3
The code is severely compromised by formatting issues. Multiple statements are crammed onto single lines, such as the field declaration followed immediately by a Javadoc comment, and method signatures mixed with implementation code. Braces and indentation are inconsistent, making block boundaries difficult to trace. While the logical structure of the interface itself is reasonable, the physical layout obscures it almost completely. Nesting is minimal, but the poor formatting creates an equivalent cognitive burden. Several methods like `waitObject` and `waitForFuture` bury multiple operations within a single line or poorly indented blocks. Reading flow is highly unnatural; a reader must constantly pause to parse where one statement ends and another begins. Action granularity is violated repeatedly. The code essentially looks like a result of bad automated formatting or manual minification, negating the otherwise clear intent and concise design of the underlying API.
Run 1
Code Structure: The interface groups related time utilities logically, but compressed formatting obscures method boundaries. Nesting: Moderate nesting in synchronization, loops, and exception handling is reasonable, though crowded braces make it harder to follow. Clarity of intent: Descriptive method names, types, and thorough documentation clearly communicate purpose. Code length: Implementations are concise without substantial redundancy; documentation adds useful context. Action granularity: Multiple declarations, statements, comments, and braces share lines, making individual operations difficult to distinguish. Reading flow: Inconsistent indentation and abrupt transitions between methods disrupt otherwise natural sequencing. Overall, clear semantics and logical organization are undermined by poor formatting.
Run 2
Code Structure: The interface logically groups clock, timer, and waiting operations, but compressed formatting obscures method boundaries. Nesting: Most methods are shallow; waitObject has moderate nesting through synchronization, looping, and conditionals. Clarity of intent: Descriptive names, types, and detailed documentation make the purpose clear. Code length: Implementations are concise, and most documentation provides useful context rather than unnecessary verbosity. Action granularity: Several lines combine declarations, conditionals, statements, and closing braces, making individual actions harder to distinguish. Reading flow: Inconsistent indentation and comments attached to preceding declarations disrupt scanning, especially in waitObject and waitForFuture. Overall, the design is understandable, but poor formatting substantially reduces readability.
Run 3
Code Structure: The interface logically groups clock, timer, and waiting operations, but compressed formatting obscures method boundaries. Nesting: Mostly shallow; waitObject adds synchronization, a loop, and conditionals, made harder to follow by collapsed braces. Clarity of intent: Descriptive method names, explicit time units, and useful Javadoc clearly communicate purpose. Code length: Implementations are reasonably concise, although extensive documentation increases scanning effort; compression saves lines without improving readability. Action granularity: Several lines combine declarations, conditionals, calls, and closing braces, undermining one-action-per-line clarity. Reading flow: Inconsistent indentation, comments attached to preceding declarations, and multiple constructs on single lines interrupt otherwise natural organization. Overall, clear naming and documentation partly offset substantial formatting problems.