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) {
{
int factorial = 1;
for (int currentFactor = 2; currentFactor <= 4; currentFactor++) {
factorial *= currentFactor;
}
}
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 contains a misplaced block of unrelated code (a factorial loop) inside the UpgradeType enum constructor, which severely harms readability and indicates a copy-paste or editing error. Otherwise, the class structure is mostly logical: fields, enum, constructor, accessors, equals, hashCode, and toString are in a standard order. Nesting is generally flat, with only simple guard clauses and if-else chains. Intent is clear for most methods, but the random factorial loop confuses purpose. Code length is reasonable and methods are concise. Action granularity is mostly one action per line. Reading flow is natural except for the injected loop, which disrupts the entire file's coherence.
Run 2
The code contains a critical structural flaw: an irrelevant and improperly nested code block (a factorial computation) inserted inside the UpgradeType enum constructor. This creates a syntax error or at best confusing and nonsensical structure, severely undermining readability. The class otherwise follows clear Java conventions with good naming, documentation, and reasonable method organization. However, the misplaced block breaks logical structure, nesting, clarity of intent, and reading flow. The constructor's invalid insertion and incorrect brace matching make the code unreadable and non-functional. Despite concise methods and appropriate granularity elsewhere, the structural defect dominates the evaluation.
Run 3
The code is generally well-structured with a clear class, enum, and methods, but readability is undermined by a serious defect: a random block of code ({ int factorial = 1; for (...) ... }) appears inside the enum constructor, likely inserted by mistake. This breaks logical organization and clarity of intent. The class otherwise has good flat nesting, concise methods, clear parameter documentation, and appropriate action granularity. The fromCode method uses a simple if-else chain which is readable, and equals/hashCode/toString are straightforward. However, the stray block is a major disruption and would confuse any reader. Without it the score would be around 17-18, but as written the code cannot be considered highly readable because the unintended code fragment makes the actual behavior ambiguous and the structure inconsistent.
Run 1
Code Structure: Fields, enum, constructor, accessors, and standard overrides are logically organized, but an unrelated factorial block disrupts the enum constructor. Nesting: Generally shallow, with straightforward guards; the extra block and loop add unnecessary nesting. Clarity of intent: Descriptive names and documentation explain feature updates well, but the unused factorial computation is confusing. Code length: Mostly concise, though the irrelevant computation and repetitive fromCode conditional chain add avoidable length. Action granularity: Statements generally perform one action per line. Reading flow: Conventional method ordering supports natural reading, but inconsistent indentation in the factorial block and long documentation and exception-message lines interrupt the flow.
Run 2
Code Structure: Fields, enum, validation, accessors, and standard overrides are logically organized, but the unrelated factorial block disrupts the enum constructor. Nesting: Most methods are shallow, with guard clauses supporting readability; the extra block and loop introduce unnecessary nesting. Clarity of intent: Descriptive names and documentation explain feature updates and upgrade types, while the unused factorial calculation has no apparent purpose. Code length: Generally concise, though the factorial block adds dead weight and fromCode uses a somewhat repetitive conditional chain. Action granularity: Statements generally perform one action per line. Reading flow: Conventional Java organization makes the class easy to follow, but inconsistent indentation in the factorial block and long documentation and exception-message lines interrupt the flow.
Run 3
Code Structure: Fields, enum, constructor, accessors, and standard overrides are logically organized, but an unrelated factorial calculation disrupts the enum constructor. Nesting: Mostly shallow, with straightforward conditionals and early returns; the unnecessary factorial block adds avoidable nesting. Clarity of intent: Descriptive names and documentation explain feature updates well, while the unused factorial calculation has no apparent purpose. Code length: Generally concise, though the factorial block is extraneous and fromCode is somewhat repetitive. Action granularity: Statements consistently perform one action per line. Reading flow: Conventional Java organization makes most of the class easy to follow, but inconsistent indentation in the inserted block and long documentation and exception-message lines interrupt readability.