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 a();
/**
* Returns the value returned by `nanoseconds` converted into milliseconds.
*/
default long b() {
return TimeUnit.NANOSECONDS.toMillis(c());
}
/**
* 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 c();
/**
* Sleep for the given number of milliseconds
*/
void d(long a);
/**
* 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 e(Object b, Supplier<Boolean> c, long d) throws InterruptedException {
synchronized (b) {
while (true) {
if (c.get())
return;
long e = a();
if (e >= d)
throw new org.apache.kafka.common.errors.TimeoutException("Condition not satisfied before deadline");
b.wait(d - e);
}
}
}
/**
* Get a timer which is bound to this time instance and expires after the given timeout
*/
default Timer f(long f) {
return new Timer(this, f);
}
/**
* Get a timer which is bound to this time instance and expires after the given timeout
*/
default Timer f(Duration g) {
return f(g.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 g(
Future<T> h,
long i
) throws TimeoutException, InterruptedException, ExecutionException {
TimeoutException j = null;
while (true) {
long k = c();
if (i <= k) {
throw (j == null) ? new TimeoutException() : j;
}
long l = i - k;
try {
return h.get(l, TimeUnit.NANOSECONDS);
} catch (TimeoutException m) {
j = m;
}
}
}
}
Run 1
The code has critical readability issues. The method names a(), b(), c(), d(), e(), f(), and g() are completely opaque and provide no indication of their purpose, forcing readers to rely solely on Javadoc. Parameter names like (Object b, Supplier<Boolean> c, long d) are meaningless single letters that obscure the logic. The wait_for_future method is deeply nested with a while loop, try-catch, and a conditional throw of a variable to preserve the original timeout exception, making the control flow hard to follow. While the code structure itself is logically organized and the Javadoc is thorough, the obfuscated naming destroys clarity of intent. The mixed use of method overloads with different parameter types (long vs Duration) combined with single-letter names makes it nearly impossible to understand calls without reading documentation. Action granularity is reasonable, and the code is concise, but the lack of expressive naming makes this effectively unreadable for a human without constant reference to the comments.
Run 2
The code is severely unreadable due to meaningless method and variable names (a(), b(), c(), d(), e(), f(), g(), plus single-letter parameters) that completely obscure intent. While the structure is logically organized and nesting is mostly shallow, the lack of descriptive names forces readers to rely solely on comments to understand behavior. Method overloading (two f() methods) and the obfuscated generic wait method g() further complicate comprehension. Action granularity is acceptable, but reading flow is disrupted by cryptic identifiers and inconsistent formatting. Overall, the code would be reasonably structured if properly named, but as written it largely fails as readable code.
Run 3
The code is almost completely unreadable due to deliberate renaming of all methods, parameters, and local variables to single-letter names (a, b, c, d, e, f, g, h, i, j, k, l, m). This destroys clarity of intent, makes the reading flow nonsensical, and breaks all semantic meaning. While the original structure is likely well-organized, the obfuscated names make it impossible to understand what the code does without reverse-engineering every single identifier. The comments and method signatures are also mismatched—e.g., method `e` takes parameter `b` (an object) and `c` (a supplier), but the parameter names no longer reflect their purpose. The code structure and nesting may be acceptable, but they cannot compensate for the complete loss of meaning. Action granularity and code length are irrelevant when every name is meaningless. This is effectively unmaintainable.
Run 1
Code Structure: The interface logically groups clock access, waiting, and timer creation into small methods. Nesting: Mostly shallow, though the synchronized wait loop and future retry loop introduce moderate nesting. Clarity of intent: Documentation explains the purpose, but single-letter method and variable names obscure behavior and time units. Several documentation references and parameter names do not match the actual identifiers, further weakening clarity. Code length: Implementations are concise; the extensive documentation is mostly useful rather than redundant. Action granularity: Each statement generally performs one action, with no crowded multi-statement lines. Reading flow: Method ordering and whitespace are sensible, but readers must repeatedly consult comments to decode identifiers. Inconsistent brace usage and the unusually split future-method signature slightly disrupt flow. Overall, solid organization is undermined primarily by opaque naming.
Run 2
Code Structure: The interface logically groups clock access, sleeping, timers, and waiting operations into separate methods. Nesting: Most methods are flat, but the synchronized waiting loop and future retry loop introduce moderate nesting. Clarity of intent: Documentation explains the functionality, but single-letter method and variable names obscure meaning and require constant cross-referencing. Several Javadoc parameter names do not match the actual parameters, and documentation references a nonexistent nanoseconds method. Code length: Implementations are concise; extensive documentation is mostly useful but cannot compensate fully for ambiguous naming. Action granularity: Statements generally perform one action per line, with no densely packed operations. Reading flow: Method ordering and early exits support natural flow, but cryptic identifiers, inconsistent formatting, and omitted braces on some conditional branches interrupt comprehension.
Run 3
Code Structure: The interface logically groups clock, sleep, timer, and waiting operations into small methods. Nesting: Most methods are flat; the synchronized condition loop and future-wait loop introduce moderate, manageable nesting. Clarity of intent: Documentation explains the operations, but single-letter method and variable names severely obscure meaning. Several documentation references and parameter names do not match the actual declarations, further reducing clarity. Code length: Implementations are concise, although extensive documentation dominates the file. Action granularity: Statements generally perform one action per line, making individual steps easy to distinguish. Reading flow: Method ordering is coherent, but readers must repeatedly consult comments to interpret identifiers and track deadlines, timestamps, and exceptions. Overall, sound organization and concise implementations are substantially undermined by uninformative naming.