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: the enum, constructor, accessors, and standard object methods are logically organized. Nesting is minimal and readable. Field and parameter names communicate intent effectively, supported by thorough Javadoc. The code is concise without sacrificing clarity, though the Javadoc is somewhat verbose. Each method performs a single action per line, contributing to strong readability. The fromCode method uses a simple if-else chain rather than a switch, which is slightly less elegant but still clear. Constructor validation is straightforward and well-ordered. Overall, the code is highly readable, with only minor opportunities for improvement such as using a switch expression or Objects.equals for consistency.
Run 2
The code is well-structured and highly readable. It follows a logical organization with clear separation of concerns: enum definition, constructor with validation, accessors, and standard overrides. Nesting is minimal; the enum's fromCode method uses simple if-else chains rather than nested logic. Intent is clearly expressed through descriptive naming and comprehensive Javadoc, especially for the constructor parameters. Code length is appropriate — no unnecessary verbosity or excessive brevity. Action granularity is good, with single operations per line in most cases. Reading flow is natural: package/imports, class declaration, enum, fields, constructor, methods, then overrides. Minor deductions: the constructor's first validation condition could be slightly clearer (checking equals against enum with three branches instead of using !=), and the Javadoc has minor formatting inconsistencies. Overall, it's production-quality public API code that balances documentation, validation, and readability well.
Run 3
The code is highly readable with clear logical organization, flat nesting, and minimal complexity. The class structure separates constants, enum, constructor, accessors, and standard methods cleanly. The enum's fromCode method uses straightforward if-else branches without deep nesting. The constructor validates inputs with clear error messages, and the javadoc effectively communicates intent and special cases. Lines are concise, each performing one logical action. The reading flow is natural—declarations, enum, constructor, methods, then standard overrides—making it easy to follow. Minor deductions: the enum could use a switch statement or Map for slightly cleaner mapping, and the equals method has a small redundance with instanceof and cast, but these do not significantly impact readability.
Run 1
Code Structure: Logically organized into immutable fields, a related enum, constructor validation, accessors, and standard object methods. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive names and documentation clearly explain feature updates and downgrade modes; the validation message saying '< 1' while its condition checks zero is slightly imprecise. Code length: Appropriately concise overall, though the enum conversion chain and lengthy constructor documentation could be streamlined. Action granularity: Statements generally perform one action per line, with compound conditions remaining easy to understand. Reading flow: Conventional Java ordering supports natural reading; minor import spacing and long lines slightly reduce polish.
Run 2
Code Structure: Well-organized value class with fields, a related enum, constructor validation, accessors, and standard object methods. Nesting: Shallow control flow and early returns make branches easy to follow. 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 repetitive if/else chain could be simplified. Action granularity: Statements generally perform one action each; longer validation and equality expressions remain understandable. Reading flow: Natural ordering and consistent formatting support easy reading, with minor distractions from long lines, uneven Javadoc alignment, and missing spacing after the package declaration.
Run 3
Code Structure: Fields, the enum, constructor, accessors, and standard object methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive names and constructor documentation clearly explain feature updates and downgrade modes; the error message's '< 1' wording does not precisely match its zero-only condition. Code length: Mostly concise, though fromCode's repetitive if/else chain could be simplified. Action granularity: Statements generally perform one action per line, with only a few long expressions and messages. Reading flow: Consistent formatting and conventional method ordering make the class easy to follow; missing spacing around imports and lengthy documentation lines slightly reduce readability.