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) {
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() {
{boolean lI0O_0380b76d=((0x4458^0x4458)!=0);lI0O_0380b76d=!(!lI0O_0380b76d);}
return Objects.hash(maxVersionLevel, upgradeType);
}
@Override
public String toString() {
return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The code is well-structured with clear separation of the enum, constructor, and getters. It avoids deep nesting and mostly follows one-action-per-line. Javadocs explain intent, especially for the constructor parameters. However, readability is hurt by a suspicious placeholder expression inside the hashCode() method: `{boolean lI0O_0380b76d=((0x4458^0x4458)!=0);lI0O_0380b76d=!(!lI0O_0380b76d);}` which is unexplained and confusing. Also, the `UpgradeType.fromCode()` method could be more concise using a switch expression. The `equals()` method is straightforward, but `upgradeType.equals()` lacks a potential null check, though it may be acceptable given constructor validation. Overall, the code is clear but the artifact in `hashCode()` reduces clarity and trust.
Run 2
The code is generally well-structured with clear class organization, appropriate use of enums, and good documentation. The constructor validation logic is explicit and understandable. However, there are notable readability issues: the hashCode() method contains an obfuscated line (seemingly dead/confusing code) that severely hurts clarity and should be removed. The equals() method has multiple conditional returns which slightly disrupt natural reading flow. The enum's fromCode() method uses an if-else chain instead of a switch, which is acceptable but slightly more verbose. The ternary-like boolean logic in hashCode is confusing and unnecessary. Overall, the code follows Java conventions well, but the mysterious boolean expression and redundant control flow prevent it from being highly readable.
Run 3
The code is well-structured with clear separation of concerns, minimal nesting, and consistent naming. The enum and constructor include useful documentation, and methods are concise with one action per line. However, a confusing obfuscated boolean fragment inside hashCode() severely hurts readability and appears to be erroneous or malicious. The equals method is logically structured, and the class follows a natural reading flow overall. If this stray block were removed, the code would be highly readable.
Run 1
Code Structure: The class is logically organized into fields, an enum, construction, accessors, and standard overrides, but hashCode contains an unrelated obfuscated block. Nesting: Mostly shallow, with straightforward validation and a simple conditional chain. Clarity of intent: Descriptive names and documentation explain feature updates well; the meaningless boolean manipulation and cryptic variable name obscure intent locally. Code length: Generally concise, though the dead block adds unnecessary code and fromCode could be more compact. Action granularity: Most lines perform one action, but the injected hashCode block compresses declaration and reassignment onto one line. Reading flow: Conventional ordering and guard clauses support natural reading; inconsistent formatting in hashCode abruptly interrupts that flow.
Run 2
Code Structure: Fields, enum, constructor, accessors, and overrides are logically organized, but an unrelated block disrupts hashCode. Nesting: Generally shallow, with straightforward validation and early returns. Clarity of intent: Descriptive names and documentation make the feature-update model clear; the cryptic variable and pointless bitwise/boolean operations in hashCode obscure intent. Code length: Mostly concise, although enum conversion is somewhat repetitive and the injected block is unnecessary. Action granularity: Most statements perform one action per line, but the hashCode block compresses declaration, calculation, and reassignment onto one line. Reading flow: Conventional Java organization supports natural reading, interrupted by the unindented obfuscated block and a few long lines.
Run 3
Code Structure: The class is logically organized into fields, an enum, validation, accessors, and standard overrides, but hashCode contains an unrelated obfuscated block. Nesting: Mostly shallow, with straightforward guards and a simple conditional chain. Clarity of intent: Descriptive names and documentation clarify feature updates; the cryptic variable and redundant Boolean operations obscure intent locally. Code length: Generally concise, though the dead block is unnecessary and fromCode could use a switch. Action granularity: Most statements perform one action per line, but the injected block compresses declaration and reassignment onto one line. Reading flow: Conventional Java organization supports natural reading, interrupted by the malformed-looking hashCode block, inconsistent spacing, and some long lines.