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(0x0),
UPGRADE(0x1),
SAFE_DOWNGRADE(0x2),
UNSAFE_DOWNGRADE(0x3);
private final byte code;
UpgradeType(int code) {
this.code = (byte) code;
}
public byte code() {
return code;
}
public static UpgradeType fromCode(int code) {
if (code == 0x1) {
return UPGRADE;
} else if (code == 0x2) {
return SAFE_DOWNGRADE;
} else if (code == 0x3) {
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 == 0x0 && 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 < 0x0) {
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 and highly readable. It follows a logical organization with clear separation of concerns: constants, enum, constructor, getters, and standard object methods. Nesting is minimal, with only simple if-else branches in fromCode and constructor validation. Intent is clear through descriptive naming and thorough Javadoc comments. The constructor validation is straightforward and error messages are informative. Action granularity is appropriate—each line performs a single logical operation. Reading flow is natural, with the enum defined before its usage and getters/overrides properly ordered. Minor improvements could include using switch in fromCode for better readability and using 'instanceof pattern matching' for equals, but these are stylistic preferences rather than readability issues.
Run 2
The code is generally clear and well-structured. The FeatureUpdate class is logically organized with fields, constructor, accessors, and standard methods in a predictable order. The enum UpgradeType is simple and flat, using straightforward if-else in fromCode. The constructor contains two validation checks that are easy to follow; no deep nesting is present. Method length is concise, and actions are generally one per line. The Javadoc explains the intent of parameters clearly. Minor deductions: the validation error message is slightly verbose, the equals method uses `instanceof` followed by a cast, and some conditions (like `upgradeType.equals(...)`) could be simplified. Overall, the code reads naturally and requires little effort to understand.
Run 3
The code is highly readable with clear structure and purpose. It uses a logical organization: class fields, enum, constructor, accessors, and standard overrides. Nesting is minimal—only simple if-checks and an else-if chain in the enum. Intent is explicit through Javadoc and method names. The constructor validation is clear and well-documented. Lines are concise and perform one logical action, though a few lines (like the exception message) are slightly long but still readable. Reading flow is natural, moving from type definition to behavior. Minor improvements could include using '==' instead of .equals() for enum comparison in the constructor, and replacing the if-else chain in fromCode with a switch expression for slightly better clarity.
Run 1
Code Structure: Logically organized into fields, an enum, constructor validation, accessors, and standard object methods. Nesting: Shallow, with straightforward conditionals and early returns. Clarity of intent: Descriptive names and documentation clearly explain feature updates and downgrade modes; hexadecimal version comparisons and slightly awkward documentation reduce clarity. Code length: Generally concise, although the enum lookup chain and long exception message could be simplified. Action granularity: Each statement performs a single clear action, with conventional compound expressions in validation and equality checks. Reading flow: Natural and consistent, supported by formatting and predictable method ordering; long lines and uneven Javadoc alignment introduce minor friction.
Run 2
Code Structure: Well-organized value object with an associated enum, constructor validation, accessors, and standard overrides. Nesting: Shallow throughout; early returns keep equals easy to follow. Clarity of intent: Descriptive names and useful documentation explain feature updates and downgrade behavior, though hexadecimal literals for ordinary version comparisons are unnecessarily obscure. Code length: Appropriately concise overall, with some repetition in fromCode and a lengthy validation message. Action granularity: Statements generally perform one action per line; wrapped exception construction remains understandable. Reading flow: Natural progression from fields and enum to construction and object methods, supported by consistent formatting. Minor weaknesses include cramped package/import spacing, uneven Javadoc alignment, and a validation message referring to '< 1' when its condition specifically checks zero.
Run 3
Code Structure: Logically organized into immutable fields, a related 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 documentation clearly explain feature updates and downgrade modes; hexadecimal literals for ordinary version comparisons slightly obscure meaning. Code length: Appropriately concise overall, although fromCode could use a switch for a more compact mapping. Action granularity: Each statement performs a distinct action, with no crowded multi-statement lines. Reading flow: Consistent formatting and conventional method ordering support natural reading. Minor distractions include lengthy documentation and an error message describing values below one when its condition specifically checks zero.