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 a) {
this.code = (byte) a;
}
public byte a() {
return code;
}
public static UpgradeType b(int b) {
if (b == 1) {
return UPGRADE;
} else if (b == 2) {
return SAFE_DOWNGRADE;
} else if (b == 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 c, final UpgradeType d) {
if (c == 0 && d.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.",
c));
}
if (c < 0) {
throw new IllegalArgumentException("Cannot specify a negative version level.");
}
this.maxVersionLevel = c;
this.upgradeType = d;
}
public short a() {
return maxVersionLevel;
}
public UpgradeType b() {
return upgradeType;
}
@Override
public boolean c(Object e) {
if (this == e) {
return true;
}
if (!(e instanceof FeatureUpdate)) {
return false;
}
final FeatureUpdate f = (FeatureUpdate) e;
return this.maxVersionLevel == f.maxVersionLevel && this.upgradeType.equals(f.upgradeType);
}
@Override
public int d() {
return Objects.hash(maxVersionLevel, upgradeType);
}
@Override
public String e() {
return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The code has a clear structure with logical separation of enum, constructor, and accessors, and includes useful documentation. However, readability is significantly hurt by poor naming: method names like a(), b(), and variables c, d, e, f obscure intent. While nesting is flat and action granularity is reasonable, the abbreviated names force readers to infer purpose. The constructor has clear validation with helpful error messages, but the enum conversion method uses an if-else chain that could be improved. Overall, the structure is sound but the naming choices reduce clarity.
Run 2
The code suffers from several readability issues. Method and parameter names are cryptic (a(), b(), c(), d(), e(), a, b, c, d, e), obscuring intent. The overridden equals(), hashCode(), and toString() methods are incorrectly named, breaking Java conventions. The enum has a static factory method instead of a proper fromCode() or valueOf pattern, and its logic is unnecessarily verbose. While the code structure is mostly flat and each line performs one action, the overall clarity of intent is severely compromised by poor naming. The JavaDoc is helpful but doesn't compensate for the confusing method names. Some positive aspects include reasonable organization, flat nesting, and concise length, but these are overshadowed by the naming issues which force readers to constantly reference the implementation to understand what each method does. The code appears deliberately obfuscated, making it difficult to read and maintain in a real codebase.
Run 3
The code has clear logical organization and good documentation, but suffers from poor naming conventions that drastically reduce readability. Method names like 'a()', 'b()', 'c()', 'd()', 'e()' obscure intent—readers cannot discern that 'a()' returns maxVersionLevel or 'b()' returns upgradeType without examining implementations. Parameter names like 'a', 'b', 'c', 'd', 'e', 'f' further compound confusion. The structure is otherwise flat and each line performs one action, with Javadoc explaining the constructor well. The UpgradeType enum uses clear value names but its method and parameter names remain cryptic. The equals() method follows a standard pattern and the logic is straightforward. Overall, the code would be significantly more readable with descriptive method and parameter names, bringing it closer to 18+; as written, the obfuscated naming drops it to a borderline-unreadable state.
Run 1
Code Structure: Fields, enum, constructor, accessors, and object-style methods are logically grouped. Nesting: Shallow conditionals and early returns keep complexity low, although the enum conversion uses a repetitive else-if chain. Clarity of intent: Descriptive fields, enum constants, and documentation help, but single-letter methods and parameters obscure purpose. Constructor documentation names do not match its parameters, and renamed methods marked @Override obscure the intended equals, hashCode, and toString contracts and would not compile as written. Code length: Generally concise, with somewhat lengthy documentation and error formatting. Action granularity: Statements mostly perform one action per line, with readable multiline expressions. Reading flow: Organization is natural, but opaque identifiers repeatedly force readers to infer behavior from method bodies.
Run 2
Code Structure: Fields, enum, constructor, accessors, and utility methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive class, field, and enum names help, but single-letter methods and parameters obscure meaning. Constructor documentation references names that do not match its parameters, and @Override annotations on c, d, and e misleadingly suggest valid Object overrides. Code length: Mostly concise, although the enum conversion conditional and long documentation add verbosity. Action granularity: Statements generally perform one action per line. Reading flow: Conventional organization and spacing support scanning, but opaque identifiers force readers to infer each method's role from its implementation.
Run 3
Code Structure: Fields, enum, constructor, accessors, and utility methods are logically organized. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive class, field, and enum names help, but single-letter methods and parameters obscure their roles. Constructor documentation references names absent from its signature, and methods c, d, and e misleadingly use @Override instead of the expected equals, hashCode, and toString signatures. Code length: Mostly concise, although the enum conversion and long documentation add some verbosity. Action granularity: Statements generally perform one action per line, with conventional compound conditions. Reading flow: The overall sequence is natural, but ambiguous identifiers, inconsistent documentation, and invalid override declarations interrupt comprehension.