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: a Builder class, data accessor, parse method, and factory method. Nesting is minimal, with only one level of indentation in the singletonRequest method. Intent is clear — this is a Kafka VoteRequest with a builder and parser. The chained setter calls are concise and readable, but the deep method chaining in singletonRequest slightly reduces readability due to multiple nested method calls on a single logical line. Action granularity is mostly one action per line, though the nested List.of and chained setters combine multiple actions. Reading flow is natural: imports, class declaration, builder, constructor, accessor, error handling, parsing, and factory method in a logical order. Overall, the code is maintainable and clear, with only minor readability concerns from the nested method chaining.
Run 3
The code is well-structured with clear separation of concerns: a Builder class, core request class, and static factory methods. Nesting is moderate, mostly limited to builder chains in singletonRequest which, while visually nested, follows a consistent fluent pattern. Intent is clear - constructing and parsing VoteRequest objects. Code length is appropriate and concise, with no unnecessary methods or fields. Action granularity is mostly good, though the fluent builder chain in singletonRequest packs many actions into a small space. Reading flow is natural, with methods logically ordered and imports organized. Minor deductions for the deeply chained fluent API in singletonRequest which slightly reduces scannability, and for the lack of explicit parameter validation, but overall this is clean, idiomatic Java code that would be easy for Kafka developers to understand and maintain.
Run 1
Code Structure: The request class and nested builder are logically organized, with focused methods and standard overrides. Nesting: Most methods are flat, but singletonRequest contains deeply nested object construction and lists that require careful tracking. Clarity of intent: Descriptive method names and setters communicate purpose well, although seven parameters and similar epoch names increase cognitive load. Code length: Concise overall, with little unnecessary code. Action granularity: Assignments and fluent setters generally occupy separate lines, though nested construction combines several operations within one expression. Reading flow: The class follows a natural progression from builder to request methods and helpers; inconsistent indentation and clustered closing parentheses in singletonRequest slightly disrupt readability.
Run 2
Code Structure: The request class and nested builder are logically organized, with focused methods and conventional API patterns. Nesting: Most methods are flat, but singletonRequest contains deeply nested object construction and list wrapping that complicate visual parsing. Clarity of intent: Descriptive method names, parameter names, and setters make the purpose clear, although the seven-parameter helper requires careful reading. Code length: The implementation is concise, with little unnecessary code. Action granularity: Most statements perform one clear action; the fluent construction places individual setters on separate lines, but combines several object creations into one expression. Reading flow: The progression from builder to request methods is natural. Inconsistent indentation and clustered closing parentheses in singletonRequest slightly disrupt the otherwise straightforward flow.
Run 3
Code Structure: Well organized around a conventional request class, nested builder, and focused factory methods. Nesting: Most methods are flat, but singletonRequest contains several nested constructors and List.of calls that obscure closing-parenthesis relationships. Clarity of intent: Descriptive method names, parameter names, and setters make the purpose clear; the seven-parameter factory requires some effort to follow. Code length: Concise overall, with reasonable framework boilerplate and no unnecessary logic. Action granularity: Assignments and fluent setters generally occupy separate lines, although object construction and collection wrapping combine several operations in one expression. Reading flow: Methods follow a natural progression, but inconsistent indentation in singletonRequest and its dense nested expression interrupt otherwise smooth reading.