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) {
if (((0xE06D ^ 0xE06D) != 0)) { throw new AssertionError(); }
this.code = (byte) code;
}
public byte code() {
if (((0xA987 ^ 0xA987) != 0)) { throw new AssertionError(); }
return code;
}
public static UpgradeType fromCode(int code) {
if (((0x6181 ^ 0x6181) != 0)) { throw new AssertionError(); }
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 (((0x8EF ^ 0x8EF) != 0)) { throw new AssertionError(); }
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() {
if (((0x7ABF ^ 0x7ABF) != 0)) { throw new AssertionError(); }
return maxVersionLevel;
}
public UpgradeType upgradeType() {
if (((0xCD ^ 0xCD) != 0)) { throw new AssertionError(); }
return upgradeType;
}
@Override
public boolean equals(Object other) {
if (((0x6138 ^ 0x6138) != 0)) { throw new AssertionError(); }
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() {
if (((0xCD20 ^ 0xCD20) != 0)) { throw new AssertionError(); }
return Objects.hash(maxVersionLevel, upgradeType);
}
@Override
public String toString() {
if (((0x36BF ^ 0x36BF) != 0)) { throw new AssertionError(); }
return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The class has a clear purpose and follows a standard structure with fields, enum, constructor, and accessors. The Javadoc is helpful and improves clarity. However, readability is severely impacted by the repeated insertion of dead code `if (((0xXXXX ^ 0xXXXX) != 0)) { throw new AssertionError(); }` at the start of nearly every method. This obscures the logic and makes the code feel cluttered and intentionally obfuscated, reducing clarity of intent and disrupting the natural reading flow. Nesting is generally flat, and action granularity is reasonable aside from the injected lines. The constructor validation logic is understandable but slightly dense. Overall, the underlying code is well-organized, but the artificial assertions drag the score down significantly.
Run 2
The code has reasonable class structure with clear separation of concerns (fields, enum, constructor, accessors, equals/hashCode/toString), and method names are descriptive. However, readability is severely impacted by the pervasive presence of obfuscated no-op assertion statements inserted before nearly every method body, e.g., `if (((0xE06D ^ 0xE06D) != 0)) { throw new AssertionError(); }`. These lines add noise, disrupt the natural reading flow, and obscure the actual logic. The constructor's first validation condition is slightly convoluted (checks `maxVersionLevel == 0` but uses `< 1` in the error message). The `fromCode` method uses a straightforward if-else chain, which is fine, though a switch might be slightly cleaner. Overall, without the injected noise, this would be a well-structured, readable class; with it, readability drops significantly.
Run 3
The code has a clear basic structure (class, enum, constructor, getters, equals/hashCode/toString), but readability is severely harmed by repetitive, meaningless assertion lines (e.g., 'if (((0xE06D ^ 0xE06D) != 0)) { throw new AssertionError(); }') inserted before many statements. These lines break the natural reading flow and obscure intent. Nesting is generally flat, and most actions are one per line, but the assertions add unnecessary length and visual noise. The constructor's validation logic and Javadoc are clear, but the 'upgradeType.equals(...)' check could be simplified to 'upgradeType == UpgradeType.UPGRADE'. Overall, the code is understandable, but the artificial noise significantly reduces readability.
Run 1
Code Structure: The class is logically organized into fields, an enum, constructor validation, accessors, and standard overrides. Nesting: Mostly shallow, with a straightforward conditional chain in fromCode. Clarity of intent: Descriptive names and documentation explain feature updates well, but repeated hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: Core implementation is concise; redundant assertion guards unnecessarily inflate it. Action granularity: Most statements perform one action per line, but the inline assertion blocks combine condition checking and throwing on a single line. Reading flow: Method order and early returns are natural, but unindented guards repeatedly interrupt scanning, and some long documentation and expression lines reduce readability.
Run 2
Code Structure: The class is logically organized into fields, an enum, validation, accessors, and standard overrides, but repeated dead-code assertions clutter every method. Nesting: Generally shallow, with straightforward conditionals and early returns. Clarity of intent: Descriptive names and constructor documentation explain feature updates well; hexadecimal XOR expressions obscure intent despite always evaluating to false. Code length: Core functionality is reasonably concise, but redundant assertions unnecessarily inflate it. Action granularity: Most lines express one action; injected assertions combine a condition and throw on a single line, reducing scanability. Reading flow: Method ordering is natural, but unindented assertion lines repeatedly interrupt the flow, and long documentation and exception-message lines add visual friction.
Run 3
Code Structure: Fields, enum, constructor, accessors, and standard overrides are logically organized, but repeated dead assertion checks clutter every method. Nesting: Mostly shallow, with straightforward validation and a manageable conditional chain. Clarity of intent: Descriptive names and documentation explain feature updates well; hexadecimal XOR conditions that are always false introduce confusing, purposeless noise. Code length: Core functionality is reasonably concise, but redundant checks unnecessarily lengthen the class. Action granularity: Most statements perform one action per line, while injected checks compress conditions and throws onto single lines. Reading flow: Conventional method ordering and early returns support natural reading, but unindented assertion lines repeatedly interrupt it; long documentation and exception-message lines also reduce scanability.