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 ensure(final String nam, final Object val) {
if (!(val instanceof String)) {
throw new ConfigException(nam + " must be a string");
}
final String end = (String) val;
if (Utils.isBlank(end)) {
return;
}
try {
HostInfo.buildFromEndpoint(end);
} catch (final ConfigException e) {
throw new ConfigException(nam, val, e.getMessage());
}
}
@Override
public String to() {
return "A host:port pair, protocol://host:port, or an empty string";
}
}
Run 1
The code is highly readable with a clear, logical structure. The validator method follows a straightforward sequence: type check, blank check, parsing with error wrapping. Nesting is minimal (one try-catch, one if block) and the flat structure aids comprehension. Intent is obvious from the class name, method names, and error messages. The code is concise without sacrificing clarity, and each line performs a single logical action. Reading flow is natural, progressing from validation checks to the core operation. Minor deductions: the abbreviated parameter name 'nam' slightly reduces clarity, and the 'to()' method's purpose could be more intuitive (it returns a usage description), but these are trivial concerns in an otherwise exemplary implementation.
Run 2
The code is well-structured and readable. It follows a logical flow: type check, blank check, and endpoint validation. Nesting is minimal with only one if statement and a try-catch block. The intent is clear—validate a server endpoint configuration. The method is concise, performing validation in a few lines without unnecessary verbosity. Each line represents one action, and the reading flow is natural from guard clauses to validation. Minor deductions: variable names 'nam' and 'end' are slightly abbreviated and could be more descriptive ('name' and 'endpoint'), and the method name 'to()' is unclear without context. Overall, the code is easy to follow and maintain.
Run 3
The code is generally readable with clear structure and intent. It's flat with minimal nesting, concise, and each line performs a single action. The validator follows a logical flow: type check, blank check, validation. However, readability is diminished by poor parameter naming ('nam', 'val', 'end') which obscures intent. The exception catching and rethrowing is slightly verbose but acceptable. The 'to()' method name is ambiguous without context, though it's an interface requirement. Overall, the code is straightforward and maintainable but would benefit from more descriptive variable names.
Run 1
Code Structure: Validation is logically organized into type checking, blank-value handling, endpoint parsing, and error reporting. Nesting: Minimal nesting and an early return keep the method easy to scan. Clarity of intent: The class name and validation steps communicate the purpose, but abbreviated names such as nam, val, and end reduce clarity; the method names ensure and to are also less descriptive than conventional validator methods. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one clear action. Reading flow: Execution follows a natural validation sequence, although the missing blank line after the package declaration slightly weakens formatting.
Run 2
Code Structure: A small, focused validator with clearly separated validation and description methods. Nesting: Shallow conditionals and an early return keep control flow simple. Clarity of intent: Type checking, blank-value acceptance, and endpoint validation are understandable, but abbreviated names such as nam, val, end, and to reduce clarity. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs a single action, making individual steps easy to follow. Reading flow: Validation progresses naturally from type checking to blank handling to endpoint parsing, followed by error translation. Consistent formatting supports readability, although a blank line after the package declaration and more descriptive names would improve it.
Run 3
Code Structure: A small, cohesive validator with logically ordered type checking, blank-value handling, and endpoint validation. Nesting: Minimal nesting and an early return keep control flow straightforward. Clarity of intent: The class name and validation operations explain the purpose, but abbreviated names such as nam, val, end, and especially to obscure meaning. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs one clear action. Reading flow: Validation proceeds naturally from basic checks to parsing and exception handling; spacing between the package declaration and imports would improve presentation.