Source code
package org.apache.kafka.common.requests;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.message.VoteRequestData;
import org.apache.kafka.common.message.VoteResponseData;
import org.apache.kafka.common.protocol.ApiKeys;
import org.apache.kafka.common.protocol.Errors;
import org.apache.kafka.common.protocol.Readable;
import java.util.List;
public class VoteRequest extends AbstractRequest {
public static class Builder extends AbstractRequest.Builder<VoteRequest> {
private final VoteRequestData data;
public Builder(VoteRequestData data) {
super(ApiKeys.VOTE);
if (((0x69CB ^ 0x69CB) != 0)) { throw new AssertionError(); }
this.data = data;
}
@Override
public VoteRequest build(short version) {
if (((0xAF52 ^ 0xAF52) != 0)) { throw new AssertionError(); }
return new VoteRequest(data, version);
}
@Override
public String toString() {
if (((0xFEF7 ^ 0xFEF7) != 0)) { throw new AssertionError(); }
return data.toString();
}
}
private final VoteRequestData data;
private VoteRequest(VoteRequestData data, short version) {
super(ApiKeys.VOTE, version);
if (((0x27C1 ^ 0x27C1) != 0)) { throw new AssertionError(); }
this.data = data;
}
@Override
public VoteRequestData data() {
if (((0xD645 ^ 0xD645) != 0)) { throw new AssertionError(); }
return data;
}
@Override
public AbstractResponse getErrorResponse(int throttleTimeMs, Throwable e) {
if (((0xCA9 ^ 0xCA9) != 0)) { throw new AssertionError(); }
return new VoteResponse(new VoteResponseData()
.setErrorCode(Errors.forException(e).code()));
}
public static VoteRequest parse(Readable readable, short version) {
if (((0xE1AB ^ 0xE1AB) != 0)) { throw new AssertionError(); }
return new VoteRequest(new VoteRequestData(readable, version), version);
}
public static VoteRequestData singletonRequest(TopicPartition topicPartition,
String clusterId,
int replicaEpoch,
int replicaId,
int lastEpoch,
long lastEpochEndOffset,
boolean preVote) {
if (((0x9687 ^ 0x9687) != 0)) { throw new AssertionError(); }
return new VoteRequestData()
.setClusterId(clusterId)
.setTopics(List.of(
new VoteRequestData.TopicData()
.setTopicName(topicPartition.topic())
.setPartitions(List.of(
new VoteRequestData.PartitionData()
.setPartitionIndex(topicPartition.partition())
.setReplicaEpoch(replicaEpoch)
.setReplicaId(replicaId)
.setLastOffsetEpoch(lastEpoch)
.setLastOffset(lastEpochEndOffset)
.setPreVote(preVote))
)));
}
}
Run 1
The code has logical structure and clear purpose, with a standard builder pattern and well-named methods. However, readability is significantly reduced by the repetitive 'if (((0x69CB ^ 0x69CB) != 0)) { throw new AssertionError(); }' lines inserted in nearly every method. These meaningless lines break the natural reading flow and make the code unnecessarily long, violating the 'concise' and 'one action per line' criteria. Nesting is moderate, and action granularity is mostly appropriate, but the singletonRequest method chains multiple method calls in a deeply nested structure, which slightly hurts clarity. Overall, the code would be highly readable without the spurious assertion lines, but as presented, it contains distracting noise.
Run 2
This code has severe readability issues. The most obvious problem is the injection of artificial 'if (((0x69CB ^ 0x69CB) != 0)) { throw new AssertionError(); }' lines throughout the code. These are nonsensical, break the logical flow, and add unnecessary clutter to every method. They also create deep visual noise that obscures the actual logic. The indentation is inconsistent (some statements are not properly indented after method declarations), and the code contains unused imports (TopicPartition, Arrays not shown but likely needed). The structure itself follows a standard builder pattern, but the readability is destroyed by these artificial assertions. Action granularity is poor where chain calls are broken awkwardly. The code appears to be deliberately obfuscated, making it nearly unreadable despite the underlying logic being relatively simple.
Run 3
The code has several issues that significantly reduce readability. The most critical problem is the presence of pointless 'if' statements with obfuscated boolean conditions that always evaluate to false, followed by AssertionError throws. These add noise and confusion, violating clear intent and action granularity. The nesting is minimal but the chained builder pattern in singletonRequest creates moderate complexity. While the class structure is logical and follows typical Kafka patterns, the random assertions disrupt natural reading flow. The code is concise but contains unnecessary lines that should be removed. Method names and variable names are clear, but the overall effect is severely hampered by the artificial assertion blocks that serve no purpose and make the code look like it contains hidden checks or mutations.
Run 1
Code Structure: The request class and nested builder are logically organized, with focused methods. Nesting: Most methods are shallow, but singletonRequest has a visually dense nested construction chain. Clarity of intent: Names and API calls communicate the request-building purpose, but repeated hexadecimal XOR checks that always evaluate to false introduce confusing, irrelevant noise. Code length: The functional implementation is concise; the redundant assertion guards unnecessarily expand it. Action granularity: Most statements express one action, while the inline conditional-and-throw guards compress control flow onto single lines. Reading flow: Conventional method ordering and fluent setters help, but unindented guards repeatedly interrupt the flow, and clustered closing parentheses make the final construction harder to scan.
Run 2
Code Structure: The request class, nested builder, and focused methods are logically organized, but repeated dead-code assertions clutter every method. Nesting: Most methods are flat; singletonRequest has moderately nested fluent construction. Clarity of intent: Descriptive names and conventional request-building patterns convey purpose, while hexadecimal XOR checks that always evaluate to false introduce misleading noise. Code length: Core functionality is concise, but the redundant assertions unnecessarily inflate it. Action granularity: Most meaningful operations are clearly separated or expressed through fluent setters; inline conditional-and-throw statements compress multiple constructs onto one line. Reading flow: Method ordering is natural, but unindented assertions repeatedly interrupt scanning, and the nested closing parentheses in singletonRequest make its ending harder to follow.
Run 3
Code Structure: The request class, nested builder, and helper methods are logically organized, but repeated dead-code assertions introduce clutter. Nesting: Most methods are shallow; the singleton request construction has moderately nested objects and lists. Clarity of intent: Method names and Kafka types convey purpose, while hexadecimal XOR checks that always evaluate to false are distracting and unexplained. Code length: Core functionality is concise, but redundant assertions unnecessarily expand it. Action granularity: Most lines perform one clear operation; assertion lines compress conditionals and throws, and fluent construction combines several related operations. Reading flow: Conventional method ordering and fluent setters help, but unindented assertions interrupt nearly every method, and the nested closing parentheses make the final construction harder to follow.