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 validatePath();
/**
* Returns the value returned by `nanoseconds` converted into milliseconds.
*/
default long parseAddress() {
return TimeUnit.NANOSECONDS.toMillis(sendAddress());
}
/**
* 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 sendAddress();
/**
* Sleep for the given number of milliseconds
*/
void apply(long age);
/**
* 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 checkBatch(Object key, Supplier<Boolean> nextToken, long localState) throws InterruptedException {
synchronized (key) {
while (true) {
if (nextToken.get())
return;
long defaultStatus = validatePath();
if (defaultStatus >= localState)
throw new org.apache.kafka.common.errors.TimeoutException("Condition not satisfied before deadline");
key.wait(localState - defaultStatus);
}
}
}
/**
* Get a timer which is bound to this time instance and expires after the given timeout
*/
default Timer write(long finalPath) {
return new Timer(this, finalPath);
}
/**
* Get a timer which is bound to this time instance and expires after the given timeout
*/
default Timer write(Duration balance) {
return write(balance.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 removeSession(
Future<T> amount,
long finalToken
) throws TimeoutException, InterruptedException, ExecutionException {
TimeoutException currentRequest = null;
while (true) {
long order = sendAddress();
if (finalToken <= order) {
throw (currentRequest == null) ? new TimeoutException() : currentRequest;
}
long profile = finalToken - order;
try {
return amount.get(profile, TimeUnit.NANOSECONDS);
} catch (TimeoutException map) {
currentRequest = map;
}
}
}
}
Run 1
The code's structure is severely undermined by obfuscated method names that don't match their documented purposes (e.g., validatePath returns time, parseAddress converts nanoseconds to milliseconds, sendAddress returns nanoseconds, apply sleeps). This makes intent unclear and reading flow disorienting. Nesting is moderate but the loop/synchronized block adds complexity. Action granularity is reasonable, but the long timeout/wait logic in checkBatch and removeSession could be simpler. Code length is acceptable but the misleading naming renders it effectively unreadable despite decent formatting.
Run 2
The code suffers from severe semantic obfuscation due to identifier names that have no relation to their actual purpose. Methods like 'validatePath' returning time, 'parseAddress' converting nanoseconds, 'sendAddress' returning nanoseconds, 'apply' sleeping, 'checkBatch' waiting for conditions, 'write' creating timers, and 'removeSession' waiting on futures make the code extremely difficult to understand. While the structure follows some logical organization with reasonable nesting depth, the disconnect between method names and their behavior destroys clarity of intent. The official Kafka Time interface uses names like 'milliseconds', 'nanoseconds', 'sleep', and 'waitObject', but these have been replaced with misleading names suggesting file operations or network functions. Documentation comments describe the correct functionality, creating cognitive dissonance. Parameters like 'age' for milliseconds, 'key' for objects, 'nextToken' for conditions, 'localState' and 'finalPath' for deadlines further obscure the code. The action granularity is acceptable, and the reading flow follows standard Java conventions, but the pervasive naming mismatch makes this practically unreadable despite being syntactically valid.
Run 3
The code has severe readability issues due to obfuscated naming. Methods like validatePath(), parseAddress(), sendAddress(), apply(), checkBatch(), write(), and removeSession() have names that do not reflect their actual purpose (e.g., getting current time, sleeping, waiting, timer creation, future waiting). This destroys clarity of intent. The structure is otherwise logical, with a flat interface and reasonable nesting depth, but the misleading names make the flow feel disorganized. Action granularity is generally good, with one action per line, and code length is reasonable. However, the import of java.time.Duration is missing, and there are unused imports (Future, TimeUnit, TimeoutException are used, but checkBatch's parameter names like 'key', 'nextToken', 'localState', 'defaultStatus' are unrelated to their roles). The Javadoc comments describe the correct behavior, creating a disconnect between documentation and implementation. Overall, while structurally sound, the obfuscated naming makes it nearly unreadable without external context.
Run 1
Code Structure: The interface logically groups clock access, waiting, and timer creation, with small, separated methods. Nesting: Mostly shallow, though synchronized loops and try/catch blocks introduce moderate nesting. Clarity of intent: Severely weakened by misleading names such as validatePath, sendAddress, removeSession, and profile, which obscure time-related operations. Documentation explains the intended behavior, but several parameter tags and method references do not match the actual identifiers. Code length: Implementations are concise; extensive documentation is generally useful rather than redundant. Action granularity: Statements typically perform one action per line, making individual operations easy to follow. Reading flow: Consistent formatting and straightforward control flow help, but readers must repeatedly translate arbitrary identifiers using the comments. Overall, sound organization and concise methods are undermined by confusing naming and inconsistent documentation.
Run 2
Code Structure: Logically organized as a time abstraction with small, focused methods. Nesting: Moderate nesting in synchronization and retry loops, but manageable with early returns. Clarity of intent: Severely weakened by misleading names such as validatePath, sendAddress, removeSession, and unrelated parameter names. Comments explain intended behavior, but several Javadoc references and parameter names do not match the code. Code length: Generally concise; detailed time-source documentation is useful rather than excessive. Action granularity: Mostly one action per line, with straightforward expressions and statements. Reading flow: Method ordering and formatting are reasonably natural, but inconsistent naming forces readers to repeatedly consult documentation and infer meaning.
Run 3
Code Structure: The interface logically groups clock access, waiting, timers, and future handling into separate methods. Nesting: Mostly shallow, though synchronized loops and try/catch blocks introduce moderate nesting. Clarity of intent: Severely weakened by misleading names such as validatePath, sendAddress, removeSession, and profile; these do not describe time-related operations. Javadoc helps explain behavior but references nonexistent parameter names and a renamed method, creating confusion. Code length: Implementations are reasonably concise, although documentation occupies much of the file. Action granularity: Generally one action per line, with straightforward expressions and statements. Reading flow: Method separation and conventional formatting support navigation, but inconsistent naming, stale documentation, and unusual signature wrapping repeatedly interrupt comprehension.