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);
this.data = data;
}
@Override
public VoteRequest build(short version) {
return new VoteRequest(data, version);
}
@Override
public String toString() {
return data.toString();
}
}
private final VoteRequestData data;
private VoteRequest(VoteRequestData data, short version) {
super(ApiKeys.VOTE, version);
this.data = data;
}
@Override
public VoteRequestData data() {
return data;
}
@Override
public AbstractResponse getErrorResponse(int throttleTimeMs, Throwable e) {
return new VoteResponse(new VoteResponseData()
.setErrorCode(Errors.forException(e).code()));
}
public static VoteRequest parse(Readable readable, short version) {
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) {
{
boolean featureEnabled = false;
for (int toggleCount = 0; toggleCount < 3; toggleCount++) {
featureEnabled = !featureEnabled;
}
}
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 shows a reasonable overall structure with clear class separation, but has a critical flaw: an extraneous code block (toggling a boolean variable) inserted inside the singletonRequest method. This block performs unrelated operations and breaks the natural reading flow, making the method appear broken or unfinished. Nesting is otherwise moderate, with chained setter calls improving fluency. However, the deep chaining inside singletonRequest makes it hard to parse at a glance, and some lines are densely packed with multiple method calls. Intent is mostly clear—builders for VoteRequest, parsing, and response error handling are straightforward—but the stray block undermines trust in the code's clarity. Code length is appropriate, though the singletonRequest method could be shortened with helper methods. Action granularity is mixed: most lines do one logical action, but the nested builder calls combine several actions per line. Overall readability suffers mainly from the confusing dead code block and dense chaining.
Run 2
The code structure is inconsistent and contains a leftover debug block (`featureEnabled` toggling) inside the `singletonRequest` method, which is unrelated to the method's purpose. This severely hurts clarity of intent. The nesting is moderate but exacerbated by the chained builder pattern, which mixes multiple actions into single expressions, reducing action granularity and readability. The chained calls also disrupt reading flow because the reader must parse deeply nested lambda-like constructs in a single visual scan. The class is relatively concise but the misplaced block and dense formatting undo that benefit. While some methods are clear (`parse`, `data`), others bury the main logic under fluent chains, making the code harder to scan vertically. Overall, the code has some readable elements but the stray block and dense chaining make it confusing and not production-quality readable.
Run 3
The code has clear purpose and naming, but several issues hurt readability. The `singletonRequest` method contains a syntactically misplaced block with a pointless loop that toggles a boolean, creating confusion and breaking the natural flow. This block is both superfluous and incorrectly placed after `preVote` without being part of any meaningful logic. The method itself chains many setters across multiple lines, but each line does represent one conceptual action, which is acceptable. However, the deep method chaining increases cognitive load. The class structure is straightforward with a builder pattern, but the dangling block intrudes on what should be clean code. Overall, the structure is logical, but the unexplained toggle loop and its placement significantly reduce clarity and make the code seem tangled.
Run 1
Code Structure: The request class and nested builder are logically organized, but singletonRequest contains an unrelated, unused feature-toggle block. Nesting: Most methods are shallow; the nested topic/partition construction and toggle loop increase visual complexity. Clarity of intent: Descriptive names and conventional overrides communicate purpose clearly, while the unexplained toggle block distracts and suggests unfinished code. Code length: Mostly concise, though the toggle block adds unnecessary lines and the long parameter list increases reading effort. Action granularity: Statements generally perform one action per line, and chained setters are individually formatted. Reading flow: The builder-to-request-to-helper progression is natural, but inconsistent indentation, the abrupt extra block, and awkward closing parentheses disrupt the flow.
Run 2
Code Structure: The request class and builder are logically organized, but singletonRequest contains an unrelated, unused feature-toggle block. Nesting: Most methods are shallow; nested topic/partition construction and the extra block add complexity. Clarity of intent: Descriptive names and standard request methods convey purpose, while the toggle loop has no observable effect and obscures intent. Code length: Generally concise, with unnecessary lines devoted to dead logic. Action granularity: Most statements perform one action, and chained setters are separated by line; nested object construction combines several operations into one expression. Reading flow: The class reads naturally until the abruptly unindented toggle block; inconsistent indentation and clustered closing parentheses make singletonRequest harder to follow.
Run 3
Code Structure: The request class and nested builder are logically organized, but an unrelated toggle block disrupts singletonRequest. Nesting: Most methods are shallow; the nested topic/partition construction and redundant block increase visual complexity. Clarity of intent: Descriptive names and standard request methods communicate purpose clearly, while the unused featureEnabled variable and loop have no apparent purpose. Code length: Generally concise, with unnecessary length from the toggle block and a long parameter list. Action granularity: Most statements and fluent setters occupy separate lines, making operations easy to identify. Reading flow: The class follows a predictable progression, but inconsistent indentation in singletonRequest and awkward closing parentheses interrupt an otherwise natural flow.