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 demonstrates strong readability through clear structure, logical organization, and well-documented intent. The class has a single responsibility and follows standard Java conventions. The constructor includes validation with helpful error messages. Methods are concise and names clearly express their purpose. The enum is properly encapsulated with clean conversion logic. Minor deductions: the 'fromCode' method uses if-else chains that could be a switch statement for slightly better clarity, and the enum field 'code' could be more descriptive as 'value' or 'typeCode'. The Javadoc is thorough but slightly verbose. Overall, the code maintains flat nesting, natural reading flow, and one action per line, making it quite maintainable.
Run 3
The code demonstrates strong readability through logical organization of a simple class representing a feature update. The enum is clear with sensible ordering, and the fromCode method, while using sequential if-else, is flat and easy to follow. Javadoc is comprehensive and explains edge cases well, particularly around the special zero value. Validation logic in the constructor is placed early, creating a clear contract. Methods are concise and single-purpose. The equals method follows standard patterns and avoids excessive nesting. Minor deductions: fromCode could use a switch statement for slightly better readability, and the constructor's first validation check contains a somewhat long condition expression and verbose error message. Overall, the code is well-structured, maintains flat nesting, and clearly communicates intent with appropriate granularity. The reading flow is natural from type definition to validation to accessors to standard object methods.
Run 1
Code Structure: Well-organized value class with an embedded enum, constructor validation, accessors, and standard object methods. Nesting: Shallow control flow; guard clauses keep validation and equality checks easy to follow. Clarity of intent: Descriptive names and constructor documentation explain feature updates and downgrade modes. Minor ambiguity arises from an error message describing '< 1' when its condition checks only zero, and implicit null handling for upgradeType. Code length: Appropriately concise overall, though fromCode uses a slightly repetitive conditional chain. Action granularity: Statements generally perform one action per line; compound boolean expressions remain understandable. Reading flow: Natural progression from fields and enum to construction, accessors, and object methods. Long documentation and exception-message lines slightly reduce scanning ease.
Run 2
Code Structure: Well-organized value class with 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 helpful documentation explain feature updates and downgrade behavior; the error message's '< 1' wording is slightly inconsistent with its zero-only condition. Code length: Appropriately concise, though fromCode's repetitive conditional chain could be simplified with a switch. Action granularity: Statements generally perform one action per line; longer expressions remain understandable. Reading flow: Logical ordering and consistent formatting make the class easy to follow, with minor distractions from long documentation and exception-message lines.
Run 3
Code Structure: Fields, the related 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, although the error message says '< 1' when its condition checks only zero. Code length: Appropriately concise overall; the enum lookup's if/else chain is slightly repetitive. Action granularity: Each statement performs a single clear action, with only some long expressions and strings reducing scanability. Reading flow: Conventional Java layout provides a natural progression, though missing spacing between package and imports, uneven Javadoc alignment, and long lines slightly detract from readability.