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 cod) {
this.code = (byte) cod;
}
public byte cod() {
return code;
}
public static UpgradeType from(int cod2) {
if (cod2 == 1) {
return UPGRADE;
} else if (cod2 == 2) {
return SAFE_DOWNGRADE;
} else if (cod2 == 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 max, final UpgradeType upgrade) {
if (max == 0 && upgrade.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.",
max));
}
if (max < 0) {
throw new IllegalArgumentException("Cannot specify a negative version level.");
}
this.maxVersionLevel = max;
this.upgradeType = upgrade;
}
public short max() {
return maxVersionLevel;
}
public UpgradeType upgrade() {
return upgradeType;
}
@Override
public boolean equ(Object oth) {
if (this == oth) {
return true;
}
if (!(oth instanceof FeatureUpdate)) {
return false;
}
final FeatureUpdate tha = (FeatureUpdate) oth;
return this.maxVersionLevel == tha.maxVersionLevel && this.upgradeType.equals(tha.upgradeType);
}
@Override
public int hash() {
return Objects.hash(maxVersionLevel, upgradeType);
}
@Override
public String to() {
return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The overall structure is clear and the class has a single responsibility. However, the code has critical readability issues: methods 'equ', 'hash', 'to' have cryptic names that obscure intent, and parameters 'oth', 'tha', 'cod', 'cod2' are poorly named. The constructor uses 'upgrade.equals()' which is brittle compared to '=='. The 'from' method uses a series of if-else statements that could be simplified with a switch expression. The Javadoc for parameters doesn't match the actual parameter names ('maxVersionLevel' vs 'max', 'upgradeType' vs 'upgrade'). While the code is mostly flat and each line performs a single action, the poor naming and inconsistency significantly hurt readability and maintainability.
Run 2
The code is generally well-structured with a clear class and enum. However, several issues reduce readability. The method names are truncated (`equ`, `hash`, `to`, `cod`), which obscures intent and violates standard Java conventions (`equals`, `hashCode`, `toString`). The enum's `from` method uses sequential `if-else` instead of a cleaner switch or lookup. The nested `String.format` in the constructor adds complexity. Some variable names (`cod`, `oth`, `tha`) are cryptic. One-sentence summary: clear structure overall but undermined by unconventional naming and minor verbosity.
Run 3
The code is generally readable with clear structure, simple nesting, and straightforward intent. The enum and main class are logically organized. However, parameter naming is inconsistent (maxVersionLevel vs max, upgradeType vs upgrade), and method names are non-standard (equ instead of equals, hash instead of hashCode, to instead of toString, cod instead of code). The enum from method uses a chain of if-else that could be a switch or mapping for readability. Comments are helpful but verbose. Overall, the code is understandable but could be improved by following Java naming conventions and tightening redundant logic.
Run 1
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 fields, enum constants, and documentation help, but abbreviated names such as cod2, oth, tha, equ, hash, and to obscure meaning. The latter three also incorrectly use @Override instead of overriding equals, hashCode, and toString, undermining familiar Java conventions. Constructor documentation names do not match its parameters. Code length: Generally concise, though the enum conversion chain and lengthy exception formatting could be simplified. Action granularity: Most statements perform one action per line, with readable validation steps. Reading flow: The overall progression is natural, but inconsistent naming, documentation mismatches, and long lines interrupt comprehension.
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 fields and enum constants help, but abbreviated names such as cod2, oth, tha, equ, hash, and to obscure meaning. The latter three also have invalid @Override annotations rather than overriding equals, hashCode, and toString. Constructor documentation names do not match its parameters. Code length: Generally concise, though enum conversion uses a repetitive if/else chain and the exception message is lengthy. Action granularity: Most lines perform one clear action. Reading flow: Consistent formatting and method grouping support scanning, but inconsistent naming and misleading documentation interrupt comprehension.
Run 3
Code Structure: Fields, the enum, validation, accessors, and utility methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive field and enum names help, but abbreviated names such as cod, cod2, oth, tha, equ, hash, and to obscure meaning. The latter three also incorrectly use @Override rather than overriding equals, hashCode, and toString, creating confusion. Constructor documentation references parameter names that do not match the signature. Code length: Mostly concise, though the enum conversion could use a switch for clearer mapping. Action granularity: Statements generally perform one action per line; wrapped expressions remain readable. Reading flow: Conventional ordering and consistent indentation support navigation, but missing spacing around imports, inconsistent naming, and mismatched documentation interrupt the flow.