Source code
package org.apache.kafka.clients.admin;
import org.apache.kafka.common.annotation.InterfaceAudience;
import java.util.Objects;
@InterfaceAudience.Public
public class FeatureUpdate {
private final short maxVersionLevel;
private final UpgradeType upgradeType;
public enum UpgradeType {
UNKNOWN(0),
UPGRADE(1),
SAFE_DOWNGRADE(2),
UNSAFE_DOWNGRADE(3);
private final byte code;
UpgradeType(int code) {
this.code = (byte) code;
}
public byte code() {
return code;
}
public static UpgradeType fromCode(int code) {
if (code == 1) {
return UPGRADE;
} else if (code == 2) {
return SAFE_DOWNGRADE;
} else if (code == 3) {
return UNSAFE_DOWNGRADE;
} else {
return UNKNOWN;
}
}
}
public FeatureUpdate(final short maxVersionLevel, final UpgradeType upgradeType) {
if (maxVersionLevel == 0 && upgradeType.equals(UpgradeType.UPGRADE)) {
throw new IllegalArgumentException(String.format(
"The upgradeType flag should be set to SAFE_DOWNGRADE or UNSAFE_DOWNGRADE when the provided maxVersionLevel:%d is < 1.",
maxVersionLevel));
}
if (maxVersionLevel < 0) {
throw new IllegalArgumentException("Cannot specify a negative version level.");
}
this.maxVersionLevel = maxVersionLevel;
this.upgradeType = upgradeType;
}
public short maxVersionLevel() {
return maxVersionLevel;
}
public UpgradeType upgradeType() {
return upgradeType;
}
@Override
public boolean equals(Object other) {
if (this == other) {
return true;
}
if (!(other instanceof FeatureUpdate)) {
return false;
}
final FeatureUpdate that = (FeatureUpdate) other;
return this.maxVersionLevel == that.maxVersionLevel && this.upgradeType.equals(that.upgradeType);
}
@Override
public int hashCode() {
return Objects.hash(maxVersionLevel, upgradeType);
}
@Override
public String toString() {
return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The code is highly readable with clear structure: fields, enum, constructor, accessors, equals, hashCode, and toString are logically organized. Nesting is minimal except for a slightly verbose fromCode method that could use a switch statement for better flow. Intent is clear throughout, especially in constructor validation messages. Code length is appropriate for a value class with proper immutability and validation. Action granularity is good—one logical operation per line. Reading flow is natural, though the scattered blank lines between fields and constructor slightly disrupt flow. The enum's fromCode method uses multiple if-else branches that are readable but a switch expression would improve clarity and reduce nesting. Error messages are descriptive and precise. Overall, the code demonstrates strong readability with only minor improvements possible.
Run 2
The code is well-structured and readable overall. The class has a clear single responsibility, with clean separation between the data model, enum, and helper methods. Nesting is minimal, with flat conditional checks and straightforward control flow. Intent is clear: the constructor validates version and upgrade type constraints, and methods like maxVersionLevel(), upgradeType(), equals(), hashCode(), and toString() have obvious purposes. Code length is appropriate for the functionality, avoiding unnecessary verbosity. Action granularity is good—most lines perform a single logical action, improving debugging and readability. Reading flow is natural, with fields, enum, constructor, accessors, and standard object overrides in a conventional order. Minor deductions: the constructor’s error message uses 'String.format' for a single interpolation, which could be simpler, and there are some blank lines that slightly disrupt visual flow. Overall, this is clean, maintainable code.
Run 3
The code is generally well-structured with a clear purpose, evident in the FeatureUpdate class and UpgradeType enum. It uses standard patterns for equals, hashCode, and toString. However, readability is slightly reduced by scattered blank lines, especially before the constructor, which disrupts visual flow. The constructor's validation logic is clear but has a minor issue: checking upgradeType.equals(UPGRADE) when maxVersionLevel is 0 could be simpler using the enum's code. The enum's fromCode method is a chain of if-else, which is acceptable for three cases but could be a switch for clarity. Nesting is minimal, but action granularity is sometimes mixed—like the combined condition and exception throwing. Overall, the code is concise and readable, with only minor formatting and organizational improvements needed.
Run 1
Code Structure: Fields, enum, constructor, accessors, and standard object methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive names make version updates and upgrade types understandable, although the constructor's error message describes a broader condition than its corresponding check. Code length: Methods are concise, but excessive blank lines add unnecessary visual length, and fromCode uses a somewhat repetitive conditional chain. Action granularity: Statements generally perform one action per line; wrapped expressions remain readable. Reading flow: The class follows a familiar Java layout, but large whitespace gaps and long validation and equality expressions slightly interrupt scanning.
Run 2
Code Structure: Fields, the related enum, constructor, accessors, and object-method overrides are logically organized. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive names make version updates and upgrade types understandable, although numeric enum mappings and the constructor's validation rules require some interpretation. Code length: Mostly concise, but excessive blank lines add visual clutter, and fromCode uses a repetitive conditional chain. Action granularity: Statements generally perform one action per line; wrapped expressions remain readable. Reading flow: Conventional Java organization supports natural top-to-bottom reading, interrupted slightly by inconsistent spacing and a lengthy validation message.
Run 3
Code Structure: Fields, the enum, constructor, accessors, and standard overrides are logically organized. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive names make version updates and upgrade types understandable, though numeric enum mappings require interpretation and the validation message describes '< 1' while its condition checks zero. Code length: Methods are concise, but excessive blank lines add unnecessary visual length, and fromCode is somewhat repetitive. Action granularity: Statements generally perform one action per line; wrapped expressions remain readable. Reading flow: Conventional Java organization supports natural reading, but large whitespace gaps and long exception and return expressions interrupt the flow.