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 is well-structured and highly readable. It follows clear organizational patterns with a builder pattern implementation, simple constructor delegation, and straightforward method overrides. Nesting is minimal except in the singletonRequest method where the chained List.of calls create some depth, but this is a common pattern that remains clear. Intent is explicit through descriptive method and variable names. Code length is concise without sacrificing clarity. Action granularity is excellent in most places, with each method performing a single logical operation. The singletonRequest method chains multiple setters but maintains readability through consistent indentation. Reading flow is natural, following a logical progression from class declaration through builder, constructor, and utility methods. Minor deductions for the multi-line chained call in singletonRequest which could be extracted, but overall this code represents production-quality readability.
Run 2
The code is well-structured with clear separation between builder, request, and factory methods. It follows a flat nesting pattern with no more than 2-3 levels of indentation, making it easy to follow. Intent is clear: parsing, building singleton requests, and error handling are self-explanatory. The code is concise without unnecessary boilerplate. Action granularity is generally good, though the singletonRequest method chains multiple actions per line, which slightly reduces readability. Reading flow is natural, with imports grouped and logically ordered. Minor deductions for the method chaining in singletonRequest and lack of inline comments explaining the pre-vote logic edge cases. Overall, the code is highly readable, consistent, and maintainable.
Run 3
The code is well-structured, with clear separation between the builder and request class. Nesting is moderate and confined to data construction in `singletonRequest`, which is reasonable for nested builders. Intent is clear: it handles VoteRequest parsing, building, and error responses. The code is concise overall but `singletonRequest` is somewhat verbose due to chained setters. Action granularity is good, though some lines combine multiple operations. Reading flow is natural and logical. Minor issues include the long chained method calls and a large parameter list, but these are acceptable for a Kafka request class.
Run 1
Code Structure: The request class and nested builder are logically organized, with small, focused methods. Nesting: Most methods are flat, but singletonRequest embeds topic and partition objects within nested List.of calls, making parentheses harder to track. Clarity of intent: Descriptive method names and setters clearly convey request construction, parsing, and error handling; the seven-parameter helper requires some attention. Code length: Concise overall, with little unnecessary code. Action granularity: Most lines contain one assignment, return, or setter, though nested construction combines several operations into one expression. Reading flow: Conventional organization supports natural reading, but inconsistent indentation and the closing parentheses in singletonRequest interrupt the flow.
Run 2
Code Structure: Well organized into a builder, constructor, accessor, error-response handler, parser, and request factory. Nesting: Most methods are flat, but singletonRequest embeds topic and partition construction within nested fluent calls, increasing visual complexity. Clarity of intent: Descriptive method names, types, and setters make the purpose clear; the seven-parameter factory requires some effort to track related values. Code length: Concise overall, with little unnecessary code and conventional builder boilerplate. Action granularity: Most lines perform one assignment, return, or setter operation, though nested constructors combine several operations within one expression. Reading flow: Methods follow a coherent progression, but inconsistent indentation and clustered closing parentheses in singletonRequest interrupt otherwise natural reading.
Run 3
Code Structure: Well organized into a builder, request accessors, error handling, parsing, and a factory method. Nesting: Most methods are flat, but singletonRequest nests fluent builders and List.of calls, making its closing parentheses harder to follow. Clarity of intent: Descriptive method names and explicit setters communicate purpose, although the seven-parameter factory requires careful reading. Code length: Concise, with little unnecessary code. Action granularity: Most statements and setters occupy separate lines; nested construction combines several operations into one expression. Reading flow: The class follows a natural progression, but inconsistent indentation and the densely nested factory slightly interrupt readability.