Source code
package org.apache.kafka.connect.converters;
import org.apache.kafka.common.config.ConfigDef;
import org.apache.kafka.common.errors.SerializationException; import org.apache.kafka.common.serialization.Deserializer; import org.apache.kafka.common.serialization.Serializer;
import org.apache.kafka.common.utils.Utils; import org.apache.kafka.common.utils.internals.AppInfoParser;
import org.apache.kafka.connect.data.Schema;
import org.apache.kafka.connect.data.SchemaAndValue;
import org.apache.kafka.connect.errors.DataException;
import org.apache.kafka.connect.storage.Converter; import org.apache.kafka.connect.storage.ConverterType;
import org.apache.kafka.connect.storage.HeaderConverter;
import org.apache.kafka.connect.storage.StringConverterConfig;
import java.util.HashMap; import java.util.Map;
/**
* {@link Converter} and {@link HeaderConverter} implementation that only supports serializing to and deserializing from number values.
* It does support handling nulls. When converting from bytes to Kafka Connect format, the converter will always return the specified
* schema.
* <p>
* This implementation currently does nothing with the topic names or header keys.
*/
abstract class NumberConverter<T extends Number> implements Converter, HeaderConverter { private final Serializer<T> serializer; private final Deserializer<T> deserializer; private final String typeName;
private final Schema schema;
/**
* Create the converter.
*
* @param typeName the displayable name of the type; may not be null
* @param schema the optional schema to be used for all deserialized forms; may not be null
* @param serializer the serializer; may not be null
* @param deserializer the deserializer; may not be null
*/ protected NumberConverter(String typeName, Schema schema, Serializer<T> serializer, Deserializer<T> deserializer) {
this.typeName = typeName;
this.schema = schema;
this.serializer = serializer;
this.deserializer = deserializer; assert this.serializer != null; assert this.deserializer != null; assert this.typeName != null;
assert this.schema != null;
}
@Override
public String version() {
return AppInfoParser.getVersion(); } @Override
public ConfigDef config() {
return NumberConverterConfig.configDef();
}
@Override
public void configure(Map<String, ?> configs) {
NumberConverterConfig conf = new NumberConverterConfig(configs); boolean isKey = conf.type() == ConverterType.KEY;
serializer.configure(configs, isKey); deserializer.configure(configs, isKey);
}
@Override
public void configure(Map<String, ?> configs, boolean isKey) {
Map<String, Object> conf = new HashMap<>(configs);
conf.put(StringConverterConfig.TYPE_CONFIG, isKey ? ConverterType.KEY.getName() : ConverterType.VALUE.getName()); configure(conf);
}
@SuppressWarnings("unchecked")
protected T cast(Object value) {
return (T) value; } @Override
public byte[] fromConnectData(String topic, Schema schema, Object value) { try { return serializer.serialize(topic, value == null ? null : cast(value)); } catch (ClassCastException e) {
throw new DataException("Failed to serialize to " + typeName + " (was " + value.getClass() + "): ", e); } catch (SerializationException e) {
throw new DataException("Failed to serialize to " + typeName + ": ", e); }
}
@Override
public SchemaAndValue toConnectData(String topic, byte[] value) {
try { return new SchemaAndValue(schema, deserializer.deserialize(topic, value)); } catch (SerializationException e) {
throw new DataException("Failed to deserialize " + typeName + ": ", e);
} } @Override public byte[] fromConnectHeader(String topic, String headerKey, Schema schema, Object value) { return fromConnectData(topic, schema, value);
}
@Override public SchemaAndValue toConnectHeader(String topic, String headerKey, byte[] value) { return toConnectData(topic, value); }
@Override
public void close() {
Utils.closeQuietly(this.serializer, "number converter serializer"); Utils.closeQuietly(this.deserializer, "number converter deserializer"); }
}
Run 1
The code has poor readability despite functional logic. The structure is tangled with multiple statements on single lines, making it difficult to scan. Nested try-catch blocks are acceptable but formatting makes them hard to follow. Intent is somewhat clear through comments but the implementation is obscured by poor formatting. The code is unnecessarily long due to line compression rather than logical verbosity. Action granularity is violated with multiple import statements and method declarations on the same line. Reading flow is disrupted by inconsistent indentation, mixed line breaks, and compacted method bodies. While the class purpose is understandable, the layout significantly impacts readability.
Run 2
The code is highly unreadable due to severe formatting issues and poor structure. Multiple declarations are crammed onto single lines, including the class header and field declarations, making it difficult to parse visually. Method bodies are compressed into one line in several places, violating the one-action-per-line principle and making control flow nearly impossible to follow. The import statements are also run together, reducing readability. While the code's intent as a number converter is somewhat discernible through naming and comments, the execution is chaotic. Nesting depth is acceptable when formatted properly, but the current layout obscures this. The code's logical organization is sound, but the physical presentation destroys its readability. It needs complete reformatting to become maintainable.
Run 3
The code has several readability issues. Class structure is acceptable, but many imports and class-level fields are compressed onto single lines, hurting the reading flow. Some methods and field declarations are collapsed into one line, violating the 'one action per line' principle. The nesting is shallow, which is good, but the try-catch blocks and method bodies are inconsistently formatted, making the logic harder to scan. Intent is mostly clear due to descriptive method names, but the mixture of compressed lines and normal formatting creates visual noise. Some null checks are done via assertions, which may not be ideal for production code clarity. Overall, the code would benefit significantly from consistent line breaks between imports, fields, and method bodies.
Run 1
Code Structure: Responsibilities are logically separated into construction, configuration, conversion, header delegation, and cleanup, but compressed formatting obscures method boundaries. Nesting: Shallow control flow and simple try/catch blocks keep complexity low. Clarity of intent: Descriptive names, documentation, and explicit exception messages clearly communicate the converter's purpose. Code length: The implementation is reasonably concise, with useful delegation and little redundant logic. Action granularity: Multiple imports, field declarations, assertions, calls, and method boundaries share lines, making individual actions difficult to scan. Reading flow: Inconsistent line breaks and crowded annotations, braces, and exception handlers repeatedly interrupt otherwise natural organization. Overall, the logic is understandable, but poor formatting substantially reduces readability.
Run 2
Code Structure: Responsibilities are logically separated into constructor, configuration, conversion, header delegation, and cleanup methods, but compressed formatting obscures boundaries. Nesting: Shallow control flow and simple try/catch blocks keep complexity low. Clarity of intent: Descriptive method and field names, standard interfaces, and documentation make the converter's purpose clear. Code length: The implementation is reasonably concise without substantial redundant logic, though excessive line compression harms readability rather than improving concision. Action granularity: Multiple imports, declarations, assertions, method calls, and even method boundaries share lines, making individual actions difficult to scan. Reading flow: The overall method order is natural, but inconsistent line breaks, inline annotations, and crowded braces repeatedly interrupt reading.
Run 3
1. Code Structure: Responsibilities are logically separated into configuration, conversion, header delegation, and cleanup methods, but compressed formatting obscures boundaries. 2. Nesting: Shallow nesting and simple try/catch blocks keep control flow manageable. 3. Clarity of intent: Descriptive names, standard interfaces, and useful documentation clearly communicate the converter's purpose. 4. Code length: The implementation is reasonably concise without unnecessary logic; however, excessive line compression reduces readability rather than improving concision. 5. Action granularity: Multiple imports, declarations, assignments, assertions, and calls share lines, making individual actions harder to scan. 6. Reading flow: Inconsistent line breaks, annotations attached to preceding braces, and inline method bodies disrupt natural top-to-bottom reading. Overall, clear design and straightforward logic are substantially undermined by poor formatting.