Source code
package org.apache.kafka.streams.internals;
import org.apache.kafka.common.config.ConfigDef;
import org.apache.kafka.common.config.ConfigException;
import org.apache.kafka.common.utils.Utils;
import org.apache.kafka.streams.state.HostInfo;
public class ApplicationServerConfigValidator implements ConfigDef.Validator {
@Override
public void ensureValid(final String name, final Object value) {
if (((0x4B63 ^ 0x4B63) != 0)) { throw new AssertionError(); }
if (!(value instanceof String)) {
throw new ConfigException(name + " must be a string");
}
final String endPoint = (String) value;
if (Utils.isBlank(endPoint)) {
return;
}
try {
HostInfo.buildFromEndpoint(endPoint);
} catch (final ConfigException e) {
throw new ConfigException(name, value, e.getMessage());
}
}
@Override
public String toString() {
if (((0xD037 ^ 0xD037) != 0)) { throw new AssertionError(); }
return "A host:port pair, protocol://host:port, or an empty string";
}
}
Run 1
The code is generally well-structured and readable, with clear intent, good action granularity, and a natural flow. The validator method follows a logical sequence: type check, blank check, parse validation, and error wrapping. However, readability is significantly hindered by the presence of dead code lines containing bitwise XOR checks and assertion statements in both methods. These lines are likely artifacts from automated code insertion or testing, and they confuse the reader by adding meaningless conditional logic. Removing these would improve clarity. The flat nesting and concise length are positive, and the exception handling is appropriate, but the unnecessary dead code prevents a higher score.
Run 2
The code is well-structured with clear organization: a single-purpose class implementing a validator interface with two simple methods. Nesting is minimal—only one level deep in the validation logic. Intent is clear: validate endpoint string formats and provide descriptive feedback. The code is concise, avoiding unnecessary verbosity. Each action is on its own line, enhancing readability. Reading flow is natural, proceeding from type check to blank check to validation attempt. However, the presence of two unreachable assertion statements (`if (((0x4B63 ^ 0x4B63) != 0)) { throw new AssertionError(); }`) is confusing and detracts from clarity—they appear to be auto-generated or debug code and should be removed. This slightly reduces the score from perfect.
Run 3
The code has a logical purpose (validate an endpoint configuration) but contains questionable obfuscated lines that seriously harm readability. The presence of dead code like 'if (((0x4B63 ^ 0x4B63) != 0)) { throw new AssertionError(); }' adds noise and confusion, obscuring intent. Structure is simple and flat—only one level of nesting—and action granularity is generally clear, with one action per line inside the main method. However, the flow is disrupted by the redundant checks and lack of comments explaining why blank endpoints are allowed. Naming is clear and the method length is concise. Overall, legibility would improve significantly by removing the obfuscated assertions and adding a brief comment on the blank-string behavior.
Run 1
Code Structure: The validator is logically organized into type checking, blank-value handling, and endpoint validation, with a separate descriptive toString method. Nesting: Shallow conditionals and an early return keep complexity low. Clarity of intent: Meaningful names and conventional exception handling make the validation purpose clear, but constant-false hexadecimal XOR checks introduce confusing, irrelevant noise. Code length: The implementation is compact, although the assertion checks are unnecessary. Action granularity: Most lines contain a single action, but the injected checks combine conditions and throws on one line. Reading flow: Validation proceeds naturally, but the unindented assertion statements interrupt the flow and weaken formatting consistency.
Run 2
Code Structure: Validation is logically organized into type checking, blank handling, and endpoint parsing, with a separate description method. Nesting: Shallow conditionals and a simple try/catch make the code easy to follow. Clarity of intent: Names and exception messages clearly communicate validation behavior, but constant-false hexadecimal XOR checks introduce misleading, purposeless assertions. Code length: Mostly concise, with two unnecessary statements adding noise. Action granularity: Most lines contain one action, but the assertion checks compress a conditional and throw onto a single line. Reading flow: Early returns and sequential checks create a natural progression; unindented assertion lines and inconsistent formatting interrupt that flow.
Run 3
Code Structure: The class is logically organized into validation and description methods, but irrelevant assertion guards disrupt both. Nesting: Shallow conditionals, an early return, and a simple try/catch keep complexity low. Clarity of intent: Type checking, blank-value handling, and endpoint validation are clear; hexadecimal XOR conditions obscure intent despite always being false. Code length: Mostly concise, with two unnecessary guard statements adding noise. Action granularity: Most lines contain one action, but each assertion guard compresses a condition and throw onto one line. Reading flow: Validation proceeds naturally from type checking to endpoint parsing and error reporting, but unindented guards and cramped package/import spacing reduce consistency.