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() {
if (((0x7DC ^ 0x7DC) != 0)) { throw new AssertionError(); }
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 {
if (((0xF0EA ^ 0xF0EA) != 0)) { throw new AssertionError(); }
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) {
if (((0x6CD8 ^ 0x6CD8) != 0)) { throw new AssertionError(); }
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) {
if (((0x8E8 ^ 0x8E8) != 0)) { throw new AssertionError(); }
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 {
if (((0x296B ^ 0x296B) != 0)) { throw new AssertionError(); }
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 structure is generally logical, with clear documentation and a well-defined interface. However, several factors significantly reduce readability. Most notably, every method begins with an obfuscated no-op assertion line (e.g., 'if (((0x7DC ^ 0x7DC) != 0)) { throw new AssertionError(); }') that adds noise, breaks the reading flow, and obscures intent. While nesting is moderate, the infinite while loops and synchronization logic add mental overhead. The 'waitObject' method relies on multiple actions and conditions, making it less granular. The 'waitForFuture' method has a multi-line catch block with a duplicated exception that could be simplified. Method signatures and Javadocs are clear, but the artificial lines inserted at the start of each method disrupt the otherwise concise and professional code. Overall, the core logic is sound, but the injected obfuscation and minor structural issues harm readability.
Run 2
The code is generally readable but contains several issues. The interface has clear Javadoc comments and logical method organization. However, it includes bizarre debug assertions like 'if (((0x7DC ^ 0x7DC) != 0)) { throw new AssertionError(); }' that are meaningless and hurt readability. Nesting levels are acceptable - the deepest is two levels in waitObject. Method names and parameters are clear. The code contains multiple actions per line in some spots (method signatures, throw statements with ternary operators). Reading flow is disrupted by the odd assertions placed after every method declaration. The waitForFuture method has a slightly awkward loop structure with a ternary throw statement that could be clearer. Overall, the core logic is understandable but the unnecessary assertions and occasional dense formatting reduce readability significantly.
Run 3
This code is a time abstraction interface that is generally well-organized and documented but contains several serious readability issues. The bizarre dead code statements like 'if (((0x7DC ^ 0x7DC) != 0)) { throw new AssertionError(); }' add no value and significantly harm clarity. The imports lack a blank line after the package declaration, and nested loops in waitObject and waitForFuture increase complexity. The while(true) loops with multiple break/return paths make control flow harder to follow. Method signatures are split awkwardly in waitForFuture. Variable naming is okay but could be clearer (e.g., 'ms' vs 'millis'). The javadoc comments are informative, which helps. Overall structure is acceptable but could benefit from extracting some logic into helper methods and removing the pointless assertion lines. The code is readable enough for experienced developers but falls short of being clean and maintainable.
Run 1
Code Structure: The interface logically groups clock access, sleeping, timers, and waiting operations, with helpful documentation. Nesting: Most methods are flat; waitObject has moderate synchronized/loop/conditional nesting, while waitForFuture remains manageable. Clarity of intent: Descriptive names and explicit time units clarify the real functionality, but repeated hexadecimal XOR checks that are always false introduce confusing, purposeless noise. Code length: Core implementations are concise; redundant assertion guards unnecessarily lengthen the code. Action granularity: Functional statements generally perform one action per line, but the injected guards compress conditions, braces, and throws onto single lines. Reading flow: Method ordering and comments support natural reading, but unindented guards interrupt every default method and inconsistent formatting weakens visual consistency.
Run 2
Code Structure: The interface logically groups clock, timer, and waiting operations, but repeated dead assertion checks add clutter. Nesting: Most methods are flat; synchronization, loops, and conditionals introduce moderate, justified nesting in waiting methods. Clarity of intent: Descriptive names and helpful documentation explain time units and deadlines well, while always-false hexadecimal XOR checks are distracting and purposeless. Code length: Functional implementations are concise, but redundant checks unnecessarily increase length. Action granularity: Most statements occupy separate lines; injected checks compress conditionals and throws onto single lines. Reading flow: Method organization and documentation support natural reading, but unindented assertion lines disrupt formatting and force readers to inspect irrelevant expressions.
Run 3
Code Structure: The interface logically groups clock, timer, and waiting operations, but repeated dead assertion checks add unrelated clutter. Nesting: Most methods are flat; synchronization, loops, and conditionals introduce moderate, justified nesting in waiting methods. Clarity of intent: Descriptive names and useful documentation explain timing semantics, while constant-false hexadecimal checks obscure intent. Code length: Functional implementations are concise, but redundant assertions unnecessarily lengthen the code. Action granularity: Most lines contain a single operation; inline assertion blocks combine conditional checks and throws on one line. Reading flow: Method ordering and documentation support natural reading, but unindented assertions repeatedly interrupt it, and inconsistent formatting slightly reduces readability.