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 readable. It follows a clear Builder pattern, with straightforward methods and minimal nesting. Each method has a single responsibility and returns immediately. The singletonRequest method uses method chaining to construct the nested data object in a flat, readable style. Although the chained call is long, it is formatted with one setter per line, preserving clarity. The class has a logical organization: Builder, constructor, data accessor, error response, and static factory methods. The only minor drawback is the slightly dense singletonRequest method, but it remains readable due to consistent indentation and setter naming. Overall, the code is clear, concise, and maintainable.
Run 2
The code is well-structured and readable. It follows Java conventions with clear separation of concerns (Builder, data access, parsing, static factory). Nesting is minimal in most methods, though 'singletonRequest' contains moderate nesting due to the nature of constructing nested data objects. Intent is clear throughout—method names and the builder pattern are self-documenting. Code length is concise with no unnecessary repetition, and each line performs a single logical action, especially in the builder and response construction. Reading flow is natural, with standard constructor and method ordering. Minor deductions: the deeply chained method calls in 'singletonRequest' slightly reduce readability if unfamiliar with the data model, and 'getErrorResponse' ignores 'throttleTimeMs', which may surprise readers.
Run 3
The code is highly readable with clear structure and intent. It follows a standard builder pattern, keeping related fields and methods together. Nesting is minimal within the class methods, though the singletonRequest method has multi-level indentation due to building nested request data. Each line generally performs one logical action, especially with chained setters, which enhances clarity. The method names are descriptive and self-documenting. The reading flow is natural—fields, builder, constructor, then methods—aligned with typical Java conventions. Code length is concise without sacrificing understandability. Minor improvements could reduce the nesting in singletonRequest, but overall the code is clean and maintainable.
Run 1
Code Structure: Well-organized request class with a conventional builder and focused methods. Nesting: Most methods are flat, but singletonRequest nests fluent object construction and lists, making closing parentheses harder to follow. Clarity of intent: Descriptive method names and setters communicate purpose; the seven-parameter helper requires some care to interpret. Code length: Concise, with little unnecessary logic or repetition beyond standard boilerplate. Action granularity: Assignments and fluent setters generally occupy separate lines, though nested constructors combine several operations into one expression. Reading flow: The class follows a natural progression from builder to request methods and helper, but inconsistent indentation and the final nested expression slightly interrupt readability.
Run 2
Code Structure: The request class and nested builder are logically organized, with focused methods and clear responsibilities. Nesting: Most methods are flat, but singletonRequest uses nested object construction and List.of calls that require careful tracking of parentheses. Clarity of intent: Descriptive method names, parameter names, and setters clearly express request creation and error handling, although the seven-parameter helper adds cognitive load. Code length: The implementation is concise, with little unnecessary code. Action granularity: Most statements perform one clear action, and chained setters appear on separate lines; nested construction combines several operations into one expression. Reading flow: The class follows a natural progression from builder to request methods and factory helpers. Inconsistent continuation indentation and the closing parentheses in singletonRequest slightly disrupt otherwise smooth reading.
Run 3
Code Structure: Logically organized into a builder, request state, and focused construction/response helpers. 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 parameter names clearly communicate purpose, though the seven-parameter helper requires careful argument tracking. Code length: Concise, with little unnecessary code; builder boilerplate is conventional. Action granularity: Most statements perform one clear action, and chained setters are separated by lines, although singletonRequest combines several object constructions into one expression. Reading flow: Conventional Java organization and short methods support natural reading, but uneven indentation and deeply composed request construction slightly interrupt the flow.