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 follows a clear builder pattern for request construction. The class has a logical organization with nested Builder and static factory methods. Nesting is controlled, with only a slightly deep but acceptable chain in singletonRequest. Intent is generally clear, especially in the builder and parse methods. Most operations are concise and each method has a single responsibility. However, the singletonRequest method is quite long and chains many method calls in a single statement, which reduces readability slightly. The import section could be better organized (e.g., grouping by origin), and the use of List.of with nested builders is compact but may be harder to follow for less experienced readers. Overall, the code is readable but could benefit from breaking the singletonRequest into smaller, named helper methods.
Run 3
The code is well-structured and readable. The Builder pattern is cleanly implemented, with a clear separation of concerns between the builder, request, and data classes. Line breaks and indentation are consistent, contributing to a natural reading flow. The `singletonRequest` method's fluent API chain is slightly nested but remains comprehensible due to its logical grouping. However, the `getErrorResponse` method is on one line and could be broken apart for improved readability, and the `singletonRequest` method's chained calls make it slightly dense. Overall, the code clearly expresses its intent, is concise, and follows established Kafka patterns, resulting in high readability.
Run 1
Code Structure: The request wrapper, nested builder, parsing method, and convenience factory are logically organized with clear responsibilities. Nesting: Most methods are flat, but singletonRequest nests fluent construction inside two List.of calls, making parentheses and object boundaries harder to follow. Clarity of intent: Descriptive method names and explicit setters communicate purpose well; the seven-parameter factory requires some attention to argument ordering. Code length: The implementation is concise, with little unnecessary code. Action granularity: Most statements and setters occupy separate lines, although nested object creation combines several construction steps into one expression. Reading flow: The class follows a natural progression from builder to core methods to factory, but inconsistent indentation and tightly grouped closing parentheses interrupt the factory's readability.
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 that requires careful tracking. Clarity of intent: Descriptive method names, parameter names, and setters clearly express request construction, parsing, and error handling. Code length: Concise, with little unnecessary code; the seven-parameter factory slightly increases cognitive load. Action granularity: Most lines perform one clear action, and chained setters are separated by line, although nested constructors and List.of calls combine several operations. Reading flow: Conventional Java organization supports natural reading, but inconsistent indentation and clustered closing parentheses in singletonRequest slightly disrupt the flow.
Run 3
Code Structure: Logically organized into a builder, request state, and focused methods. Nesting: Most methods are flat, but singletonRequest uses nested object construction and List.of calls that require careful tracking. Clarity of intent: Descriptive names and explicit setters make the request contents clear; the seven-parameter factory adds some cognitive load. Code length: Concise overall, with little unnecessary code beyond standard builder boilerplate. Action granularity: Most statements and setter calls occupy separate lines, although the chained factory expression combines several construction steps. Reading flow: Methods follow a natural progression, but inconsistent indentation and clustered closing parentheses in singletonRequest slightly interrupt scanning.