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) {
final int a = 2;
final int b = -1;
final int c = 1;
final int d = 1;
final int e = 1;
final int f = 2;
if (code == (a + b)) {
return UPGRADE;
} else if (code == (c + d)) {
return SAFE_DOWNGRADE;
} else if (code == (e + f)) {
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) {
final int g = 1;
final int h = -1;
if (maxVersionLevel == (g + h) && 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));
}
final int i = 1;
final int j = -1;
if (maxVersionLevel < (i + j)) {
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 has a clear class structure with reasonable documentation, but it is severely undermined by obfuscated constants and needless arithmetic. The developer introduced variables like 'a', 'b', 'c', 'd', etc., and then calculates simple values (e.g., a+b for 1, c+d for 2). This obscures intent, increases code length, and violates the principle of action granularity. The fromCode method should map codes directly to enum values; the constructor should simply compare maxVersionLevel < 0 or maxVersionLevel == 0. The rest of the class (equals, hashCode, toString, accessors) is readable and well-structured, but the central logic is unnecessarily tangled, making the code hard to follow and maintain.
Run 2
The code is unnecessarily obfuscated by replacing simple constants with arbitrary variables. For example, `final int a = 2; final int b = -1;` then `if (code == (a + b))` instead of simply `if (code == 1)`. This pattern is repeated throughout the constructor, making it very hard to understand the logic. The excessive and meaningless variable names (`g`, `h`, `i`, `j`) obscure the intent of the boundary checks (e.g., `maxVersionLevel == 0` or `maxVersionLevel < 0`). While the class structure itself is standard and the Javadocs are detailed, the core logic is deeply flawed in terms of clarity. The reader must perform mental arithmetic to deduce basic integer comparisons. This severely impacts readability, negating the benefits of the otherwise logical organization and proper method names. The intent is hidden behind pointless indirection.
Run 3
The code has a clear structure with proper encapsulation and documentation, but readability is severely undermined by obfuscated comparisons. The 'fromCode' method uses meaningless variables (a, b, c, d, e, f) and arithmetic operations (e.g., a + b) instead of direct numeric constants, obscuring intent. Similarly, the constructor uses meaningless variables (g, h, i, j) and arithmetic (g + h, i + j) instead of literals like 0 or -1. These patterns force readers to perform mental arithmetic to understand simple checks. The nested if-else chain in 'fromCode' is shallow but confusing due to variable naming. While the code is concise and well-organized, the deliberate obfuscation of logic makes it unnecessarily difficult to read and maintain. The action granularity and flow are acceptable, but clarity of intent is compromised.
Run 1
Code Structure: The class is logically organized into fields, an enum, constructor validation, accessors, and standard overrides. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive API names and documentation explain the feature update, but meaningless variables a–j and arithmetic expressions obscure straightforward numeric comparisons. Code length: Most methods are concise, although unnecessary constant declarations inflate fromCode and the constructor. Action granularity: Statements generally perform one action per line, with conventional compound conditions. Reading flow: The overall progression is natural, but readers must mentally evaluate artificial arithmetic to understand mappings and validation. Direct numeric comparisons or meaningful constants would substantially improve readability.
Run 2
Code Structure: Fields, enum, constructor, accessors, and standard overrides are logically organized. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive API names and documentation explain the class, but meaningless variables a–j and arithmetic expressions obscure straightforward numeric comparisons. Code length: Mostly concise, although unnecessary constants inflate fromCode and constructor validation. Action granularity: Statements generally perform one action per line; compound comparisons remain manageable. Reading flow: Conventional Java layout supports natural reading, but repeated arithmetic indirection interrupts comprehension, and long documentation and exception-message lines reduce scanability.
Run 3
Code Structure: Fields, enum, constructor, accessors, and standard overrides are logically organized. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive API names and documentation explain the class, but meaningless variables a–j and arithmetic expressions obscure simple constants and validation rules. Code length: Mostly compact, though unnecessary constant declarations inflate fromCode and the constructor. Action granularity: Statements generally perform one action per line, with conventional compound conditions. Reading flow: Familiar Java conventions support natural reading, but scattered arithmetic setup interrupts otherwise straightforward logic. Direct comparisons against literal values or named constants would substantially improve readability.