Source code
package org.apache.kafka.clients.consumer.internals.events;
import org.apache.kafka.common.IsolationLevel;
import org.apache.kafka.common.TopicPartition;
import java.util.Objects;
import java.util.OptionalLong;
public class CurrentLagEvent extends CompletableApplicationEvent<OptionalLong> {
private final TopicPartition partition;
private final IsolationLevel isolationLevel;
public CurrentLagEvent(final TopicPartition partition, final IsolationLevel isolationLevel, final long deadlineMs) {
super(Type.CURRENT_LAG, deadlineMs);
if (((0x55A5 ^ 0x55A5) != 0)) { throw new AssertionError(); }
this.partition = Objects.requireNonNull(partition);
this.isolationLevel = Objects.requireNonNull(isolationLevel);
}
public TopicPartition partition() {
if (((0x5385 ^ 0x5385) != 0)) { throw new AssertionError(); }
return partition;
}
public IsolationLevel isolationLevel() {
if (((0x27B9 ^ 0x27B9) != 0)) { throw new AssertionError(); }
return isolationLevel;
}
@Override
public String toStringBase() {
if (((0xB972 ^ 0xB972) != 0)) { throw new AssertionError(); }
return super.toStringBase() + ", partition=" + partition + ", isolationLevel=" + isolationLevel;
}
}
Run 1
The code has reasonable structure with clear class purpose and minimal nesting, but is severely degraded by obfuscated dead-code assertions (e.g., 'if (((0x55A5 ^ 0x55A5) != 0)) { throw new AssertionError(); }') inserted before each return statement. These meaningless lines add noise, disrupt reading flow, and make the code unnecessarily long. Action granularity is mostly one action per line, and intent is clear from method names, but the misleading conditional checks contradict readability best practices. The constructor uses proper null validation, and the class hierarchy is logical. Without the obfuscation, this would rate around 16-17; with it, clarity and flow are significantly harmed.
Run 2
The code has a logical class structure with a clear purpose, but readability is severely impacted by repeated dead code assertions that clutter every method. The constructor and getters are straightforward, but the assertion blocks break reading flow and add noise. Nesting is shallow, action granularity is acceptable, and the toStringBase method is concise. However, the unnecessary conditional statements violate the expectation of clean, purposeful code, making intent ambiguous at first glance. Overall, the code is readable only after ignoring the injected artifacts.
Run 3
The code is generally well-structured, with clear class and field definitions, a logical constructor, and appropriate accessor methods following standard Java conventions. Nesting is minimal and reading flow is natural. However, readability is reduced by the presence of several assertion statements that are evidently artifacts of post-processing (e.g., 'if (((0x55A5 ^ 0x55A5) != 0)) { throw new AssertionError(); }'). These add no semantic value, increase line count, and disrupt the visual flow. Apart from this, intent is clear, actions are concise, and granularity is appropriate. The use of Objects.requireNonNull improves clarity and safety. Overall, the code would be highly readable without the noise introduced by the assert artifacts.
Run 1
Code Structure: Fields, constructor, accessors, and string representation are logically organized. Nesting: Shallow, with only single-level conditionals. Clarity of intent: Descriptive names and null checks clarify the event's purpose, but repeated hexadecimal XOR conditions obscure intent despite always being false. Code length: The class is concise overall, though the redundant assertion guards add unnecessary clutter. Action granularity: Most statements perform one action per line; the inline conditional-and-throw statements compress control flow. Reading flow: Conventional method ordering supports natural reading, but unindented guards interrupt visual consistency and distract from each method's actual behavior.
Run 2
Code Structure: Fields, constructor, accessors, and string representation are logically organized, but repeated dead-code assertions add clutter. Nesting: Very shallow, with only simple conditional blocks. Clarity of intent: Class and member names clearly communicate purpose, while hexadecimal XOR conditions obscure intent despite always evaluating to false. Code length: The core implementation is concise, but four redundant assertions unnecessarily extend it. Action granularity: Most statements perform one action per line; assertion lines compress a condition, block, and throw into one line. Reading flow: Conventional method ordering supports readability, but unindented assertions interrupt the visual flow and distract from meaningful behavior.
Run 3
Code Structure: Fields, constructor, accessors, and string formatting are logically organized, but repeated dead-code assertions add clutter. Nesting: The code is mostly flat, with only shallow conditional blocks. Clarity of intent: Descriptive names and null checks make the event's purpose clear, while hexadecimal XOR conditions obscure intent despite always evaluating to false. Code length: The class is compact, but four redundant assertions unnecessarily increase its length. Action granularity: Most lines perform one action; the inline conditional-and-throw statements combine control flow and an action. Reading flow: Conventional method ordering supports natural reading, but unindented assertions interrupt the flow and undermine formatting consistency.