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 (!(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() {
{int lI0O_57de2d0b=0x2821;lI0O_57de2d0b=((lI0O_57de2d0b&0)==0)?(((lI0O_57de2d0b^lI0O_57de2d0b)==0)?0:1):2;}
return "A host:port pair, protocol://host:port, or an empty string";
}
}
Run 1
The code is generally readable with clear intent and logical structure. It follows a flat control flow with minimal nesting and one primary action per line. The validation logic is straightforward: type-check, blank-check, then parse validation. However, the toString() method contains an obfuscated, meaningless block of code that serves no purpose, significantly harming readability. Removing that would improve clarity. Overall, the class is concise and well-structured despite this anomaly.
Run 2
The code is generally readable but is undermined by an obfuscated artifact in the toString() method. The intended purpose of the validator is clear, and the validation logic follows a straightforward flow with low nesting and good action granularity. However, the bizarre obfuscated block (a meaningless arithmetic statement with a cryptic variable name) introduces confusion and ambiguity, severely impacting readability. The method structure is logical, but the toString() listing disrupts the natural reading flow and appears to be either a decompilation artifact or deliberate obfuscation. The overall intent is understandable, but the unexplained noise lowers the score significantly.
Run 3
The code is generally readable due to its simple, flat structure and clear validation logic. It follows a natural flow: check type, check blank, validate endpoint. The one-line-per-action pattern (instanceof check, blank check, try/catch) is good. Improvements could include simplifying the exception handling and removing the obfuscated dead code. Overall, the code is understandable but has a notable cleanup issue.
Run 1
Code Structure: Validation is logically organized, but an unrelated obfuscated block disrupts toString(). Nesting: Early returns keep validation shallow; the added block contains needlessly nested ternary expressions. Clarity of intent: Type checking, blank handling, and endpoint validation are clear, while the cryptic variable and bitwise expressions have no apparent purpose. Code length: Mostly concise, except for the unnecessary computation. Action granularity: Validation uses one action per line, but the obfuscated block compresses declaration and assignment onto one line. Reading flow: The main method reads naturally; inconsistent formatting and irrelevant logic interrupt the otherwise straightforward flow.
Run 2
Code Structure: The validator is logically organized into validation and description methods, but an unrelated block in toString disrupts that organization. Nesting: Validation remains shallow through guard clauses; the added block contains nested ternaries that complicate reading. Clarity of intent: Type checking, blank handling, and endpoint validation are clear, while the cryptic variable and hexadecimal arithmetic have no apparent purpose. Code length: Most code is concise, but the unused computation adds unnecessary length. Action granularity: Validation generally uses one action per line; the inserted line combines declaration, assignment, and several expressions. Reading flow: The validation sequence reads naturally, but the densely packed, poorly formatted block interrupts an otherwise straightforward description method.
Run 3
Code Structure: The validator is logically organized into validation and description methods, but an unrelated block disrupts toString(). Nesting: Validation stays shallow through guard clauses; the extraneous block adds nested ternary expressions. Clarity of intent: Type checking, blank handling, and endpoint validation are clear, whereas the cryptically named variable and redundant bitwise operations obscure intent. Code length: Most code is concise, but the pointless computation adds unnecessary complexity. Action granularity: Validation generally uses one action per line; the inserted block compresses declaration, assignment, and conditional logic onto one line. Reading flow: ensureValid() reads naturally, but the unindented, densely packed block abruptly interrupts the otherwise straightforward flow.