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) {
{int lI0O_6907c4d9=0x862E^0x862E;if(lI0O_6907c4d9!=0){if(((lI0O_6907c4d9|1)&1)==0){lI0O_6907c4d9++;}else{lI0O_6907c4d9--;}}}
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 mostly readable due to clear naming, logical structure, and standard patterns like the Builder. However, notable issues reduce clarity. There is an obfuscated, dead code block in getErrorResponse that appears to do nothing and interrupts reading flow. The singletonRequest method uses deep method chaining, which nests logical actions at a low level and hurts flattening and readability. Multiple chained calls occur per line, reducing action granularity. Some method signatures are long but acceptable. Overall, the code follows typical Kafka request patterns and is understandable, but the extraneous block and dense chaining prevent a higher score.
Run 2
The code is generally well-structured with clear separation of concerns (builder, data access, error response, parsing). Nesting is moderate but acceptable. However, readability is significantly impacted by several issues: the meaningless line of machine-generated obfuscated code inside getErrorResponse; the singletonRequest method returns VoteRequestData rather than VoteRequest, which is confusing given its name; and the deeply chained builder call in singletonRequest creates dense, hard-to-scan code. While the class follows consistent patterns and has clear intent overall, these problems disrupt reading flow and clarity.
Run 3
The code has reasonable structure and naming, but several issues reduce readability. The most serious problem is a line of obfuscated/dead code inserted into getErrorResponse(), which is confusing and serves no purpose. The builder pattern and request parsing are clear, but the singletonRequest method contains deeply nested builder calls (4 levels), making it hard to follow. The method also returns VoteRequestData instead of VoteRequest, violating the naming expectation. Missing import for ApiKeys is a minor issue. The code alternates between clean sections and dense nested chains, disrupting reading flow. Action granularity is inconsistent—some lines have single actions while others chain multiple method calls. Overall structure is logical but the obfuscated line and deep nesting significantly hurt clarity.
Run 1
Code Structure: The request wrapper, builder, parser, and factory are logically organized, but an unrelated no-op block disrupts getErrorResponse. Nesting: Most methods are flat; the factory has moderately nested construction, while the injected block adds unnecessary nested conditionals. Clarity of intent: Descriptive method names and standard request patterns clarify the main purpose, but the cryptic variable and redundant bitwise operations obscure the no-op block. Code length: Most methods are concise, though the injected logic is entirely unnecessary. Action granularity: Most statements and chained setters occupy separate lines; the injected block compresses declarations, conditions, and mutations onto one line. Reading flow: The overall progression is natural, but inconsistent formatting, deeply indented factory construction, and the abrupt obfuscated block interrupt readability.
Run 2
Code Structure: The class is logically organized into a builder, constructor, accessors, and factory methods, but an unrelated block disrupts error handling. Nesting: Most methods are flat; the nested fluent construction is manageable, while the injected block contains unnecessary nested conditionals. Clarity of intent: Descriptive names and standard request patterns communicate purpose well, except for the cryptic variable and pointless bitwise operations in getErrorResponse. Code length: Generally concise, with unnecessary dead code adding noise. Action granularity: Most statements and setter calls occupy separate lines, but the injected block compresses declarations, conditions, and mutations onto one line. Reading flow: Conventional method ordering supports navigation, though the obfuscated block and awkward indentation around nested List.of calls interrupt otherwise natural reading.
Run 3
Code Structure: The request class is logically organized into a builder, accessors, response handling, parsing, and a factory method, but an unrelated block disrupts error handling. Nesting: Most methods are shallow; singletonRequest has moderately nested object construction, while the injected block adds unnecessary nested conditionals. Clarity of intent: Descriptive method names and protocol types clarify the main purpose, but the cryptic variable and redundant bitwise operations obscure intent. Code length: Generally concise, except for the useless block and somewhat elaborate factory expression. Action granularity: Most statements and setter calls occupy separate lines; the injected block compresses multiple statements and branches onto one line. Reading flow: Conventional class layout and fluent setters support reading, but inconsistent indentation, dense parentheses, and the obfuscated block interrupt the flow.