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 and demonstrates good readability. It follows a clear class hierarchy (Builder pattern, AbstractRequest), with logical grouping of methods. Nesting is minimal except in `singletonRequest`, where the nested builder calls are justified by the data structure. Intent is clear: the Builder constructs requests, `data()` exposes data, and `getErrorResponse` handles errors concisely. Method and variable names are descriptive. The code is concise without sacrificing clarity, with each line generally focused on one action. The reading flow is natural, moving from constructor to builder to static utility methods. Minor deductions: the deeply chained `singletonRequest` could be slightly more readable with temporary variables, and `getErrorResponse` ignores `throttleTimeMs` without comment.
Run 3
The code is well-structured and readable. It follows a clear builder pattern, keeping class organization logical. Nesting is minimal except in the singletonRequest method, where a chain of builders creates some indentation, but the fluent API keeps intent clear. Each method has a single responsibility, and action granularity is mostly one per line. Variable and method names are descriptive, enhancing clarity. The reading flow is natural, moving from the builder to request construction, parsing, and response handling. Minor deductions come from the moderately nested builder chain in singletonRequest and the missing newline between the package and imports, but overall the code is concise, maintainable, and easy to follow.
Run 1
Code Structure: The request class is logically organized into a builder, data access, error handling, parsing, and a convenience factory. Nesting: Most methods are flat, but singletonRequest has deeply nested object construction and list wrapping. Clarity of intent: Descriptive method names and explicit setters communicate purpose well, though several similarly named epoch parameters require attention. Code length: Concise, with little unnecessary code. Action granularity: Most statements and setter calls occupy separate lines; nested constructor expressions combine several actions but remain manageable. Reading flow: Conventional Java patterns support a natural progression, although inconsistent indentation and clustered closing parentheses in singletonRequest interrupt the flow.
Run 2
Code Structure: The request class, nested builder, parsing method, and convenience factory are logically organized with clear responsibilities. Nesting: Most methods are flat, but singletonRequest contains several nested constructors and List.of calls, making its closing parentheses harder to follow. Clarity of intent: Descriptive method names, types, and setters communicate purpose well, although the seven-parameter factory requires careful reading. Code length: The implementation is concise without unnecessary logic or repetition beyond standard builder boilerplate. Action granularity: Most statements perform one clear action; fluent setters appear on separate lines, though singletonRequest combines substantial object construction into one expression. Reading flow: Short methods and conventional Java patterns provide a natural flow, slightly weakened by inconsistent indentation in the factory and tightly packed imports.
Run 3
Code Structure: Well-organized request class with a distinct builder and focused methods. Nesting: Most methods are flat, but singletonRequest nests topic and partition construction inside fluent setters, increasing visual complexity. Clarity of intent: Descriptive method names, parameter names, and setters make the purpose clear; the seven-parameter factory requires some attention. Code length: Concise, with little unnecessary code or repetition beyond standard builder boilerplate. Action granularity: Most statements perform one action, and chained setters are separated by line; nested constructor calls combine several operations within expressions. Reading flow: Methods follow a natural progression from construction to access, error handling, parsing, and convenience creation. Inconsistent indentation and clustered closing parentheses in singletonRequest slightly disrupt an otherwise readable flow.