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 size) {
this.code = (byte) size;
}
public byte load() {
return code;
}
public static UpgradeType sendNode(int flag) {
if (flag == 1) {
return UPGRADE;
} else if (flag == 2) {
return SAFE_DOWNGRADE;
} else if (flag == 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 defaultSession, final UpgradeType nextBalance) {
if (defaultSession == 0 && nextBalance.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.",
defaultSession));
}
if (defaultSession < 0) {
throw new IllegalArgumentException("Cannot specify a negative version level.");
}
this.maxVersionLevel = defaultSession;
this.upgradeType = nextBalance;
}
public short validateBalance() {
return maxVersionLevel;
}
public UpgradeType readBalance() {
return upgradeType;
}
@Override
public boolean submit(Object price) {
if (this == price) {
return true;
}
if (!(price instanceof FeatureUpdate)) {
return false;
}
final FeatureUpdate node = (FeatureUpdate) price;
return this.maxVersionLevel == node.maxVersionLevel && this.upgradeType.equals(node.upgradeType);
}
@Override
public int schedule() {
return Objects.hash(maxVersionLevel, upgradeType);
}
@Override
public String readUser() {
return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The code has a clear class and enum structure, but naming is inconsistent and misleading, which obscures intent. Parameters and methods have names unrelated to their purpose (e.g., `defaultSession`, `nextBalance`, `sendNode`, `load`, `validateBalance`). The `sendNode` method uses a chain of if-else blocks that could be simplified with a switch, though it is not deeply nested. Action granularity is mostly one action per line, but the constructor has a long multi-line exception message that breaks flow. The `submit` method is hard to follow due to poorly named parameters and a confusing cast. The `UpgradeType` enum mixes byte codes and role names (e.g., `size`) further reducing clarity. Overall, the code is moderately structured but readability suffers from ambiguous naming and lack of alignment with the domain model.
Run 2
The code structure is disorganized due to misleading naming choices that obscure intent. Parameters and methods use names unrelated to their actual purpose ('defaultSession', 'nextBalance', 'validateBalance', 'readBalance', 'submit', 'schedule', 'readUser', 'sendNode', 'load'), violating Java conventions and making the code ambiguous. The constructor logic is flat and relatively clear, but the enum method 'sendNode' uses an if-else chain that could be simplified with a switch. Action granularity is acceptable, but reading flow suffers from the semantic mismatch between names and functionality. While the code is not deeply nested and length is concise, the pervasive naming issues severely reduce readability and maintainability. Overall, the code appears functionally structured but intentionally obfuscated through poor naming, making it difficult to understand without significant effort.
Run 3
The code uses highly misleading naming throughout: parameters like `defaultSession`, `nextBalance`, `price`, `node`, and methods like `validateBalance()`, `readBalance()`, `submit()`, `schedule()`, `readUser()` bear no relation to their intended purpose (feature version levels, upgrade types, equality, hashing, toString). The `sendNode()` method name is equally confusing. The enum uses a parameter named `size` for an int code, and `load()` for a getter. Multiple actions are packed into single lines (e.g., the boolean return in `submit()`). Constructor logic checks `equals` on an enum using `.equals()` instead of `==`, and error messages are inconsistent. While the Javadoc is decent, the implementation contradicts it, making the code ambiguous and hard to follow despite being structurally simple.
Run 1
Code Structure: Fields, enum, constructor, accessors, and comparison methods are logically grouped. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Meaningful field and enum names are undermined by misleading names such as defaultSession, nextBalance, sendNode, and readUser. Constructor documentation references different parameter names, and submit, schedule, and readUser misleadingly use @Override instead of recognizable equals, hashCode, and toString methods. Code length: Generally concise, though the enum conversion chain and lengthy validation message add minor verbosity. Action granularity: Most lines perform one clear action, with conventional multiline expressions. Reading flow: Consistent formatting and ordering support scanning, but unrelated naming forces readers to infer purpose from implementations rather than signatures.
Run 2
Code Structure: Fields, enum, constructor, accessors, and comparison methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Severely weakened by misleading names such as defaultSession, nextBalance, sendNode, and validateBalance. Constructor documentation names parameters that do not exist, and submit, schedule, and readUser appear intended as equals, hashCode, and toString but have invalid @Override annotations. Code length: Generally concise, though the enum conversion chain and long validation message add verbosity. Action granularity: Most lines perform one action; multiline expressions remain understandable. Reading flow: Consistent indentation and method separation support scanning, but unrelated naming and documentation mismatches repeatedly interrupt comprehension.
Run 3
Code Structure: Fields, enum, constructor, accessors, and utility methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Meaningful field and enum names contrast with misleading names such as defaultSession, nextBalance, sendNode, and readUser. Constructor documentation names do not match its parameters. Methods apparently intended as equals, hashCode, and toString have unrelated names and invalid @Override annotations, obscuring their roles. Code length: Generally concise, though the enum lookup could be more compact. Action granularity: Most lines perform one clear action; the combined equality expression remains manageable. Reading flow: Conventional layout and consistent indentation help, but inconsistent terminology forces readers to repeatedly infer how parameters and methods relate to feature updates.