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 schedule, Schema window, Serializer<T> localEvent, Deserializer<T> sharedRecord) {
this.typeName = schedule;
this.schema = window;
this.serializer = localEvent;
this.deserializer = sharedRecord;
assert this.serializer != null;
assert this.deserializer != null;
assert this.typeName != null;
assert this.schema != null;
}
@Override
public String archive() {
return AppInfoParser.getVersion();
}
@Override
public ConfigDef export() {
return NumberConverterConfig.configDef();
}
@Override
public void sendState(Map<String, ?> profile) {
NumberConverterConfig user = new NumberConverterConfig(profile);
boolean count = user.type() == ConverterType.KEY;
serializer.configure(profile, count);
deserializer.configure(profile, count);
}
@Override
public void sendState(Map<String, ?> address, boolean index) {
Map<String, Object> mode = new HashMap<>(address);
mode.put(StringConverterConfig.TYPE_CONFIG, index ? ConverterType.KEY.getName() : ConverterType.VALUE.getName());
sendState(mode);
}
@SuppressWarnings("unchecked")
protected T copy(Object price) {
return (T) price;
}
@Override
public byte[] validateSession(String batch, Schema buffer, Object group) {
try {
return serializer.serialize(batch, group == null ? null : copy(group));
} catch (ClassCastException map) {
throw new DataException("Failed to serialize to " + typeName + " (was " + group.getClass() + "): ", map);
} catch (SerializationException age) {
throw new DataException("Failed to serialize to " + typeName + ": ", map);
}
}
@Override
public SchemaAndValue removeMessage(String value, byte[] limit) {
try {
return new SchemaAndValue(schema, deserializer.deserialize(value, limit));
} catch (SerializationException key) {
throw new DataException("Failed to deserialize " + typeName + ": ", key);
}
}
@Override
public byte[] validateRequest(String state, String nextOrder, Schema option, Object cache) {
return validateSession(state, option, cache);
}
@Override
public SchemaAndValue validateAddress(String order, String localItem, byte[] score) {
return removeMessage(order, score);
}
@Override
public void clear() {
Utils.closeQuietly(this.serializer, "number converter serializer");
Utils.closeQuietly(this.deserializer, "number converter deserializer");
}
}
Run 1
This code is extremely unreadable due to severely obfuscated naming. Method names like 'validateSession', 'removeMessage', 'sendState', and 'archive' replace standard Converter methods (fromConnectData, toConnectData, configure, version), completely obscuring intent. Parameter names such as 'schedule', 'window', 'localEvent', 'sharedRecord', 'batch', 'group', 'price', 'limit', 'option', and 'cache' are nonsensical in context. Error handling is broken: a catch block references 'map' outside its scope, causing a compile error. The constructor uses assertions instead of proper null checks. Although the structure is flat and lines are concise, the pervasive misnaming destroys clarity, flow, and maintainability.
Run 2
The code structure is generally logical and organized, with clear separation of concerns. However, readability is severely impacted by misleading method and parameter names that do not reflect their purpose (e.g., 'archive' for version retrieval, 'export' for configDef, 'validateSession' for serialize). This obfuscates intent and breaks the natural reading flow. Nesting is low and action granularity is acceptable, but the semantic mismatch between names and operations is a major clarity issue. The code also includes an unused variable (count) and catches an exception variable that is not used in the error message, which adds confusion. While the class is concise, the poor naming makes it hard to understand what each method actually does, violating the clarity-of-intent criterion.
Run 3
The code is severely unreadable due to pervasive misleading naming throughout. Method names like archive(), export(), sendState(), validateSession(), removeMessage(), validateRequest(), and validateAddress() have no relation to their actual behavior (e.g., archive() returns a version string, export() returns a ConfigDef). The constructor parameter names (schedule, window, localEvent, sharedRecord) are nonsensical for their intended purpose. The copy() method only performs an unchecked cast, not a copy, and error handling is inconsistent (a catch block references an undefined variable 'map' instead of 'age'). While the class has a clear high-level structure as a Converter implementation, the obfuscated naming and incorrect exception handling make it almost impossible to discern intent or maintain. The code demonstrates poor clarity, misleading abstractions, and broken logic, earning it a very low readability score.
Run 1
Code Structure: Fields, initialization, configuration, conversion, and cleanup are logically separated into methods. Nesting: Minimal nesting and straightforward try/catch blocks make control flow easy to follow. Clarity of intent: Strongly weakened by misleading method and parameter names such as archive, sendState, schedule, and price. Constructor documentation names do not match the parameters. An undefined map reference in a catch block and questionable @Override method names further confuse interpretation. Code length: Compact, with little unnecessary code and useful delegation. Action granularity: Generally one statement per line, although serialization expressions combine null handling, casting, and conversion. Reading flow: Conventional class organization helps, but inconsistent terminology forces readers to infer each method's actual purpose; sparse spacing between some methods also reduces scanability.
Run 2
Code Structure: Fields, construction, configuration, conversion, and cleanup are logically separated into small methods. Nesting: Minimal nesting and straightforward try/catch blocks keep complexity low. Clarity of intent: Severely weakened by misleading method and parameter names such as archive, sendState, schedule, and price; constructor documentation also names parameters that do not exist. The serialization exception handler references map outside its scope, further confusing intent and making the code invalid. Code length: Generally concise, with little unnecessary repetition and useful delegation for header conversions. Action granularity: Statements mostly perform one action per line, although conversion calls combine casting, null handling, and serialization. Reading flow: Method organization is natural, but inconsistent vocabulary, tightly packed imports, and mismatched documentation interrupt comprehension. Overall, clean structural mechanics are undermined by pervasive naming problems and an erroneous exception reference.
Run 3
Code Structure: Fields, construction, configuration, conversion, and cleanup are separated into small methods, providing sensible organization. Nesting: Mostly flat, with only simple try/catch blocks and conditional expressions. Clarity of intent: Severely weakened by misleading method and parameter names such as archive, sendState, schedule, and window; constructor documentation names do not match its parameters. An exception handler also references map instead of its declared exception age, disrupting understanding and compilation. Code length: Concise overall, with reasonable delegation and little unnecessary repetition. Action granularity: Generally one operation per line, although serialization expressions combine null handling, casting, and method calls. Reading flow: Method boundaries and consistent indentation help, but unrelated identifiers, mismatched documentation, and sparse spacing between some methods force readers to repeatedly infer the intended converter operations.