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() {
return "A host:port pair, protocol://host:port, or an empty string";
}
}
Run 1
The code is highly readable. It follows a clear logical structure: type check, blank check, validation, and error wrapping. The method is flat with no deep nesting. Each action is on its own line, and the intent is straightforward. The toString method clearly documents acceptable formats. Minor improvements could include a more descriptive exception message, but overall the code is concise, well-organized, and easy to follow.
Run 2
The code is highly readable with a clear, logical structure. It has minimal nesting, uses early returns effectively, and maintains a single responsibility per method. The intent is explicit: validate a configuration value as an endpoint string, allowing blank values. Action granularity is good, with one action per line. The flow is natural—type check, blank check, then validation. The toString method is concise and self-documenting. Minor deductions: no comments (though not needed), and the exception handling could be slightly more explicit with a variable name.
Run 3
The code is well-structured with a single-purpose validator class and clear method separation. Nesting is minimal—only one level of control flow with early return for blank values. Intent is explicit: validate endpoint strings, return early for blanks, and wrap exceptions with context. The code is concise without being cryptic. Each logical action is on its own line, and the reading flow is natural: type check, blank check, validation, exception wrapping. The toString override clearly documents accepted formats. Minor deductions: string concatenation for error messages could use constants, and the try-catch could be slightly flatter by validating format beforehand, but overall readability is excellent.
Run 1
Code Structure: A small, focused validator cleanly separates validation from the descriptive toString method. Nesting: Guard clauses and an early return keep nesting shallow. Clarity of intent: Descriptive names, explicit type checking, and delegation to HostInfo.buildFromEndpoint make the purpose clear; the description documents accepted formats. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each statement performs a single action, and exception handling is explicit. Reading flow: Validation proceeds naturally from type checking to blank-value handling, endpoint parsing, and contextual error reporting. Minor formatting improvements, such as a blank line after the package declaration and before the try block, would improve visual separation.
Run 2
Code Structure: Validation is logically organized into type checking, blank-value handling, and endpoint parsing. Nesting: Guard clauses keep nesting shallow, with only a simple try/catch. Clarity of intent: Descriptive class and method names make the purpose clear; toString documents accepted formats. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each statement performs one clear action. Reading flow: The method progresses naturally from basic checks to detailed validation, preserving configuration context when reporting parsing errors. Minor formatting improvements, such as separating the package declaration from imports, would improve visual organization.
Run 3
Code Structure: The class cleanly separates validation from its descriptive string representation. Nesting: Guard clauses keep the method flat, with only a simple try-catch block. Clarity of intent: The class name, method names, and validation checks clearly communicate endpoint validation; the toString description reinforces accepted formats. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one distinct action, making individual steps easy to follow. Reading flow: Validation proceeds naturally from type checking to blank-value handling, endpoint parsing, and contextual error reporting. Minor readability limitations are the missing blank line between the package declaration and imports and reliance on HostInfo.buildFromEndpoint to reveal the exact validation rules.