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 with clear separation of concerns between the Builder, request, and parsing logic. It follows common Kafka patterns, making intent relatively clear. The nesting in singletonRequest is moderate but controlled, using method chaining that is readable. Action granularity is generally one property per line in the chained setters, which aids readability. However, the singletonRequest method is somewhat long and indentation-heavy, though not excessive. The Builder and parse methods are concise. Overall, the code is readable but could be slightly improved with better formatting or extracted helpers in the factory method.
Run 2
The code is well-structured, with a clear separation between the builder, request data, and factory methods. It follows a flat, non-deeply nested style; the only minor nesting is in `singletonRequest`, where building nested `TopicData` and `PartitionData` requires some indentation, but it remains readable. Clarity of intent is high: method and class names are self-explanatory, and the purpose of each method is obvious. Code length is appropriate — no excessive boilerplate beyond what the framework requires. Action granularity is good: each builder call is on its own line, improving readability. Reading flow is natural, with fields, constructors, and methods ordered logically. Minor deductions: `singletonRequest` returns a `VoteRequestData` rather than a `VoteRequest`, which slightly breaks intuitive naming, and imports are not formatted with blank lines between packages. Overall, highly readable.
Run 3
The code is highly readable with a clear, logical structure. The Builder pattern is properly separated from the request class, and methods are concise with single responsibilities. Nesting is minimal and intentional, appearing only in the singletonRequest factory method where it mirrors the natural data hierarchy. Intent is immediately clear through descriptive method and parameter names. Code length is efficient without sacrificing clarity. The main readability challenge is the singletonRequest method's chained builder pattern, which, while fluent, creates moderate nesting depth. Additionally, the error response method performs multiple actions (creating response, setting error code) in a single expression, slightly reducing action granularity. Overall, the code follows Kafka's standard patterns well and would be easily understood by developers familiar with the codebase.
Run 1
Code Structure: Well organized into a builder, request state, and focused factory/override methods. Nesting: Most methods are flat, but singletonRequest nests topic and partition construction, making closing parentheses harder to follow. Clarity of intent: Descriptive method names and explicit setters communicate purpose clearly; the seven-parameter factory adds some cognitive load. Code length: Concise, with little unnecessary code. Action granularity: Most statements and setter calls occupy separate lines, although nested object creation combines several construction steps into one expression. Reading flow: Methods follow a natural progression, but inconsistent indentation and the deeply chained singletonRequest expression slightly interrupt readability.
Run 2
Code Structure: Logically organized into a builder, request state, and focused request methods. Nesting: Most methods are flat, but singletonRequest contains nested constructors and List.of calls that require careful tracking. Clarity of intent: Descriptive class, method, and setter names make the purpose clear; the seven-parameter helper adds some cognitive load. Code length: Concise, with little unnecessary code and appropriately short methods. Action granularity: Most lines perform one assignment or setter operation, although nested object construction combines several actions within one expression. Reading flow: The class follows a natural progression, but inconsistent indentation and clustered closing parentheses in singletonRequest interrupt otherwise smooth reading.
Run 3
Code Structure: Well organized around a request class, nested builder, and focused construction, parsing, and response methods. Nesting: Most methods are flat, but singletonRequest nests fluent calls and List.of expressions, making closing parentheses harder to follow. Clarity of intent: Descriptive method names, types, and setters communicate purpose clearly; the seven-parameter factory requires some effort to track. Code length: Concise overall, with conventional builder boilerplate and no obvious unnecessary logic. Action granularity: Assignments and most setter calls occupy separate lines, though nested object creation combines several operations within one expression. Reading flow: Natural and consistent through most of the class, with uneven indentation and deeply chained construction disrupting flow near the end.