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) { 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 suffers from severe readability issues primarily due to formatting. Multiple declarations and method definitions are crammed onto single lines, violating action granularity and reading flow principles. While the overall logic is not deeply nested, the dense layout obscures the class structure and makes it difficult to parse individual actions. Naming is conventional and intent can be inferred, but the presentation completely undermines clarity. The import section groups packages unnaturally, further hampering initial comprehension. This code is functional but requires significant reformatting to be maintainable.
Run 2
The code has poor readability due to multiple issues. The package and imports are crammed onto one line, violating standard Java formatting. Several methods are placed on single lines with multiple actions per line (e.g., getErrorResponse, singletonRequest), making the flow difficult to follow. The builder constructor places the super call and field assignment on the same line. Method indentation is inconsistent - some methods are inline with class declarations while others are properly separated. The nesting in singletonRequest is moderately deep but the chained method calls with inline List.of() make it harder to parse. While the class structure is logically organized and method names are clear, the formatting severely impacts readability. The intent of each method is discernible but requires extra effort due to the compact formatting. Overall, the code functions but violates common Java style conventions, making it significantly harder to read and maintain than properly formatted equivalent code.
Run 3
The code suffers from severe formatting issues that significantly hurt readability. Multiple statements are crammed onto single lines, especially in the builder class and singletonRequest method, violating the 'one action per line' principle. The import statements are also collapsed onto one line. Inconsistent brace placement and indentation make the structure hard to follow. While the overall class structure is logical, the formatting obscures it. The singletonRequest method has deep method chaining across lines that is hard to parse. The code would be substantially more readable with standard Java formatting - proper line breaks, consistent indentation, and one statement per line. The logic itself is straightforward, but presentation makes it unnecessarily difficult to read.
Run 1
Code Structure: The request class, nested builder, and helper methods are logically organized, but compressed formatting obscures their boundaries. Nesting: Control-flow nesting is minimal; nested object construction in singletonRequest is harder to follow. Clarity of intent: Descriptive names, standard overrides, and explicit setters communicate the purpose well. Code length: The implementation is concise without substantial redundancy, although excessive compression reduces readability. Action granularity: Multiple imports, declarations, statements, and chained setters share lines, making individual actions difficult to scan. Reading flow: Inconsistent indentation, inline annotations, and closing braces adjacent to new declarations repeatedly interrupt the reading flow. Overall, the underlying design is understandable, but poor formatting significantly undermines readability.
Run 2
Code Structure: The request class and nested builder have sensible responsibilities, but compressed imports and merged method boundaries obscure their organization. Nesting: Control-flow nesting is minimal, although nested object construction and List.of calls make singletonRequest harder to follow. Clarity of intent: Descriptive method names, parameter names, and fluent setters clearly communicate the request-building purpose. Code length: The implementation is concise without substantial redundancy, but excessive compression reduces readability rather than simplifying it. Action granularity: Multiple imports, statements, annotations, declarations, and setter calls share lines, making individual actions difficult to scan. Reading flow: Inconsistent indentation and braces placed alongside unrelated declarations interrupt otherwise logical progression through the class. Conventional formatting and one declaration or action per line would substantially improve readability.
Run 3
Code Structure: The request class, nested builder, and helper methods are logically organized, but compressed boundaries obscure that structure. Nesting: Control-flow nesting is minimal; nested object construction and List.of calls make singletonRequest harder to follow. Clarity of intent: Descriptive method names, parameter names, and setters communicate purpose clearly. Code length: The implementation is concise without substantial redundancy, but excessive compression sacrifices readability. Action granularity: Imports, annotations, declarations, braces, and multiple setter calls frequently share lines, making individual actions difficult to scan. Reading flow: Inconsistent indentation and line breaks disrupt otherwise natural progression through the class, especially in singletonRequest.