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 of concerns (Builder, private constructor, static factory methods). Nesting is limited to the fluent API call in singletonRequest, which reads naturally. Intent is explicit—each method has a single responsibility and naming is descriptive. The code is concise without sacrificing clarity. Actions are generally one per line, especially in the fluent chain. Reading flow is logical: class definition, builder, core methods, then utility. Minor deductions: the singletonRequest method has a slightly deep nested structure, and the getErrorResponse method combines error resolution with response construction on one line. Overall, highly readable with only trivial readability concerns.
Run 3
The code is generally well-structured and readable. It follows a clear builder pattern, separates concerns effectively, and maintains a shallow nesting level. Class organization is logical—constructor, data accessor, parse method, and static factory. Intent is mostly clear, though the `getErrorResponse` method's purpose could be slightly more explicit. The `singletonRequest` method uses method chaining effectively but becomes a bit dense with nested `List.of` calls; while it avoids deep indentation, vertical eye movement increases. Action granularity is mostly one action per line, though the chained setters bundle multiple operations per line. Overall, concise and idiomatic Kafka code with no major readability blockers, but the nested list construction slightly reduces clarity.
Run 1
Code Structure: The builder, request data, and helper methods are logically organized with clear responsibilities. Nesting: Most methods are flat, but singletonRequest nests fluent setters and List.of calls, making closing parentheses harder to follow. Clarity of intent: Descriptive method and field names communicate purpose well, although the seven-parameter helper requires careful reading. Code length: The implementation is concise, with little unnecessary code. Action granularity: Most lines perform one assignment, return, or setter operation; nested construction expressions combine several actions but remain reasonably legible. Reading flow: The conventional class layout and short methods support natural reading, while inconsistent indentation in singletonRequest slightly disrupts it.
Run 2
Code Structure: Logically organized into a builder, request state, and focused factory/response methods. Nesting: Most methods are flat; singletonRequest has moderately nested object construction and closing parentheses that require extra attention. Clarity of intent: Descriptive method names, types, and setters make the request's purpose clear, though the seven-parameter factory adds cognitive load. Code length: Concise, with little unnecessary code and appropriate framework boilerplate. Action granularity: Statements generally perform one action, and chained setters appear on separate lines; nested construction combines several related actions in one expression. Reading flow: Natural progression and consistent formatting support easy reading, with minor friction from singletonRequest's indentation and nested fluent chains.
Run 3
Code Structure: Well organized into a builder, request state, and focused construction/response methods. Nesting: Most methods are flat, but singletonRequest nests fluent setters and List.of calls, making parentheses harder to track. Clarity of intent: Descriptive names and conventional request patterns clearly communicate purpose; the seven-parameter factory requires some care to understand. Code length: Concise, with little unnecessary code. Action granularity: Most statements perform a single clear action, and fluent setters generally occupy separate lines, though nested object creation combines several operations in one expression. Reading flow: The class follows a natural progression, but inconsistent indentation and dense closing parentheses in singletonRequest interrupt otherwise smooth reading.