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() {
return Objects.hash(maxVersionLevel, upgradeType);
} @Override public String toString() { return String.format("FeatureUpdate{maxVersionLevel:%d, upgradeType:%s}", maxVersionLevel, upgradeType);
}
}
Run 1
The code has several readability issues. The formatting is inconsistent: the class annotation is on the same line as the Javadoc closing tag, and multiple statements are crammed onto single lines (e.g., the equals method and toString). Deep nesting occurs in the fromCode method with nested if-else statements. The constructor validation logic is compressed onto one line, making it harder to follow. Enums are formatted poorly with multiple constants on one line and methods placed immediately after without line breaks. While naming is generally clear and the Javadoc is helpful, the erratic indentation and line breaks significantly hurt readability. Some methods like maxVersionLevel() and upgradeType() are simple but spread across multiple lines unnecessarily. The code structure is logical but the physical layout undermines clarity, requiring readers to slow down and reformat mentally.
Run 2
The code has severe readability issues. The enum declaration and constructor are compressed onto single lines, making them difficult to parse. The constructor body is placed on the same line as its signature, violating basic formatting conventions. Multiple statements are combined on single lines throughout, especially in the equals() and toString() methods. The equals() method chains the instanceof check, cast, and return statement on one line. While the logic itself is straightforward, the formatting is inconsistent and non-standard, with some methods properly spaced and others compressed. The Javadoc comment is well-written, but the overall visual presentation is chaotic. The intent is clear enough from the code, but the inconsistent formatting severely hampers readability. This would fail any standard Java code review based on formatting alone despite the underlying logic being sound.
Run 3
The code is functionally complete but severely compromised in readability. Formatting is chaotic: multiple statements share lines, braces are inconsistently placed, and indentation is irregular. For example, the enum constants are packed together with methods on the same line, and the fromCode method uses a deeply nested else-if chain with poor line breaks. The constructor contains multi-line conditions and throws statements that are hard to parse. Equals, hashCode, and toString are crammed together without spacing. While the Javadoc provides some clarity about intent, the physical layout obscures structure and makes the code visually noisy. The logic itself is simple, but the presentation requires significant effort to parse. Action granularity is violated repeatedly—multiple actions per line are common. Reading flow is disorganized, with no visual separation between members. A full reformatting with consistent indentation, line breaks, and one-action-per-line would substantially improve readability. As written, it falls well below acceptable production standards for clarity.
Run 1
1. Code Structure: Fields, enum, constructor, accessors, and standard overrides are logically organized, but compressed formatting obscures their boundaries. 2. Nesting: Nesting is shallow; the enum's conditional chain is straightforward despite awkward brace placement. 3. Clarity of intent: Descriptive names and constructor documentation clearly communicate feature-update behavior and validation rules. 4. Code length: The implementation is reasonably concise, though several lines are excessively long. 5. Action granularity: Multiple declarations, statements, annotations, and closing braces share lines, particularly in equals(), fromCode(), and toString(), reducing scanability. 6. Reading flow: Inconsistent line breaks, inline method bodies, and crowded block endings repeatedly interrupt otherwise natural organization.
Run 2
Code Structure: Fields, enum, constructor, accessors, and overrides are logically organized, but compressed formatting obscures their boundaries. Nesting: Control flow is shallow, although clustered braces make it harder to follow. Clarity of intent: Descriptive names and constructor documentation clearly explain feature updates and upgrade types. Code length: The implementation is reasonably concise, but several excessively long lines hinder scanning. Action granularity: Multiple declarations, statements, annotations, and control-flow elements share lines, particularly in fromCode, equals, and toString. Reading flow: Conventional member ordering helps, but inconsistent line breaks, inline closing braces, and crowded method bodies repeatedly interrupt natural reading.
Run 3
Code Structure: The class logically groups fields, an enum, validation, accessors, and standard overrides, but compressed formatting obscures boundaries. Nesting: Control flow is shallow, although crowded braces make the conditional chain harder to follow. Clarity of intent: Descriptive names and constructor documentation clearly explain feature updates and upgrade types. Code length: The implementation is reasonably concise, but long lines reduce scanability rather than improving readability. Action granularity: Several lines combine declarations, conditionals, returns, annotations, and closing braces, especially in fromCode, equals, and toString. Reading flow: Method ordering is natural, but inconsistent line breaks, inline annotations, and tightly packed statements repeatedly interrupt reading. Conventional formatting and one statement per line would substantially improve readability.