Source code
package org.apache.kafka.clients.admin;
import org.apache.kafka.common.annotation.InterfaceAudience;
import java.util.Objects;
/**
* Encapsulates details about an update to a finalized feature.
*/
@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;
}
}
}
/**
* @param maxVersionLevel The new maximum version level for the finalized feature.
* a value of zero is special and indicates that the update is intended to
* delete the finalized feature, and should be accompanied by setting
* the upgradeType to safe or unsafe.
* @param upgradeType Indicate what kind of upgrade should be performed in this operation.
* - UPGRADE: upgrading the feature level
* - SAFE_DOWNGRADE: only downgrades which do not result in metadata loss are permitted
* - UNSAFE_DOWNGRADE: any downgrade, including those which may result in metadata loss, are permitted
*/
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 well-structured with clear separation of concerns: an enum, constructor, getters, and object method overrides are logically organized. Nesting is minimal—only the enum and validation checks introduce shallow depth. Intent is explicitly documented with Javadoc, especially for constructor parameters and upgrade types. The code is concise but not overly compact, maintaining readability. Action granularity is mostly one action per line, though the constructor validation could be slightly more spaced. Reading flow is natural, following a top-down progression from type definitions to behavior. Minor deductions: the enum's fromCode uses an if-else chain that could be a switch for clarity, and the constructor's validation logic slightly condenses multiple concerns. Overall, highly readable with only small opportunities for refinement.
Run 2
The code is well-structured with clear separation of concerns: enum definition, constructor validation, accessors, and standard object overrides. Nesting is minimal, with only flat conditional checks in the constructor and equals method. Intent is clearly documented via Javadoc and descriptive names. The code is concise without being terse, though the UpgradeType.fromCode method could be simplified with a switch statement or map lookup. Action granularity is appropriate—one logical operation per line. Reading flow is natural: fields, enum, constructor, getters, then overrides. The validation logic in the constructor is clear and defensive. Overall, this is highly readable production-quality code that follows Java conventions well.
Run 3
The code is well-structured and highly readable. It follows a clear logical organization: fields, enum, constructor, accessors, and standard object method overrides. Nesting is minimal, with only a few flat if-else branches and simple validation checks. Intent is clearly expressed through descriptive names and thorough Javadoc comments. Code length is appropriate—no unnecessary verbosity or redundancy. Each action is generally confined to one line, and the reading flow follows a natural top-down progression from type definition to behavior. Minor improvements could include using a switch in `fromCode` to avoid chained if-else, and ensuring null-safety in `upgradeType.equals(...)`, but these do not significantly detract from readability.
Run 1
Code Structure: Well-organized value class with an embedded enum, constructor validation, accessors, and standard object methods. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive names and useful documentation clearly explain feature updates and downgrade modes; the validation message's '< 1' wording is slightly inconsistent with its zero-only condition. Code length: Generally concise, though fromCode's if/else chain and lengthy constructor documentation add minor verbosity. Action granularity: Statements generally perform one action per line, with readable compound conditions. Reading flow: Natural progression from fields and enum to construction and object behavior; long lines and uneven documentation alignment slightly reduce scanability.
Run 2
Code Structure: Well-organized value class with fields, a related enum, constructor validation, accessors, and standard overrides. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive names and documentation clearly explain feature updates and downgrade modes; the error message's '< 1' wording is slightly inconsistent with its zero-only condition. Code length: Mostly concise, though fromCode's if/else chain is somewhat repetitive and some documentation and strings are long. Action granularity: Statements generally perform one action per line, with only straightforward compound conditions. Reading flow: Conventional method ordering and consistent formatting support natural reading; missing spacing around imports and lengthy lines slightly reduce scanability.
Run 3
Code Structure: Logically organized into fields, an enum, constructor validation, accessors, and standard object methods. Nesting: Shallow conditionals and early returns keep control flow simple. Clarity of intent: Descriptive names and Javadoc clearly explain feature updates and downgrade behavior; the error message's '< 1' wording is slightly inconsistent with its zero-only condition. Code length: Appropriately concise overall, although fromCode's repetitive conditional chain could be simplified. Action granularity: Each statement performs a single clear action, with no crowded multi-statement lines. Reading flow: Conventional Java ordering and consistent formatting make the class easy to scan; long documentation and exception-message lines slightly interrupt the flow.