Source code
package org.apache.kafka.streams.processor.internals; import org.apache.kafka.common.config.TopicConfig; import java.util.Collections;
import java.util.HashMap; import java.util.Map;
import java.util.Objects;
/**
* WindowedChangelogTopicConfig captures the properties required for configuring
* the windowed store changelog topics.
*/
public class WindowedChangelogTopicConfig extends InternalTopicConfig {
private static final Map<String, String> WINDOWED_STORE_CHANGELOG_TOPIC_DEFAULT_OVERRIDES;
static { final Map<String, String> tempTopicDefaultOverrides = new HashMap<>(INTERNAL_TOPIC_DEFAULT_OVERRIDES);
tempTopicDefaultOverrides.put(TopicConfig.CLEANUP_POLICY_CONFIG, TopicConfig.CLEANUP_POLICY_COMPACT + "," + TopicConfig.CLEANUP_POLICY_DELETE); WINDOWED_STORE_CHANGELOG_TOPIC_DEFAULT_OVERRIDES = Collections.unmodifiableMap(tempTopicDefaultOverrides); }
private final long retentionMs;
WindowedChangelogTopicConfig(final String name, final Map<String, String> topicConfigs, final long retentionMs) {
super(name, topicConfigs);
this.retentionMs = retentionMs;
}
/**
* Get the configured properties for this topic. If no retentionMs override is provided from
* the topic configs, then we add additionalRetentionMs to work out the desired retention
* when cleanup.policy=compact,delete
*
* @param additionalRetentionMs - added to retention to allow for clock drift etc
* @return Properties to be used when creating the topic
*/ @Override public Map<String, String> properties(final Map<String, String> defaultProperties, final long additionalRetentionMs) {
// internal topic config overridden rule: library overrides < global config overrides < per-topic config overrides
final Map<String, String> topicConfig = new HashMap<>(WINDOWED_STORE_CHANGELOG_TOPIC_DEFAULT_OVERRIDES); topicConfig.putAll(defaultProperties);
topicConfig.putAll(topicConfigs); if (!topicConfigs.containsKey(TopicConfig.RETENTION_MS_CONFIG)) {
long retentionValue;
try {
retentionValue = Math.addExact(retentionMs, additionalRetentionMs);
} catch (final ArithmeticException swallow) {
retentionValue = Long.MAX_VALUE;
}
topicConfig.put(TopicConfig.RETENTION_MS_CONFIG, String.valueOf(retentionValue));
} return topicConfig; } @Override
public boolean equals(final Object o) { if (this == o) {
return true; } if (o == null || getClass() != o.getClass()) { return false; } final WindowedChangelogTopicConfig that = (WindowedChangelogTopicConfig) o;
return Objects.equals(name, that.name) &&
Objects.equals(topicConfigs, that.topicConfigs) && Objects.equals(retentionMs, that.retentionMs) &&
Objects.equals(enforceNumberOfPartitions, that.enforceNumberOfPartitions);
}
@Override
public int hashCode() { return Objects.hash(name, topicConfigs, retentionMs, enforceNumberOfPartitions); } @Override
public String toString() {
return "WindowedChangelogTopicConfig(" +
"name=" + name +
", topicConfigs=" + topicConfigs +
", retentionMs=" + retentionMs +
", enforceNumberOfPartitions=" + enforceNumberOfPartitions + ")"; }
}
Run 1
The code has poor readability due to severe formatting issues. Multiple statements are packed onto single lines, import declarations are combined, and method signatures/bodies are compressed together, violating the 'one action per line' principle. While the intent of the class is documented and the logic is straightforward (configuring windowed changelog topics), the physical layout makes it difficult to follow. The static initializer block, properties() method, equals(), hashCode(), and toString() are all crammed into minimal vertical space. Nesting is acceptable with only one try-catch block, and the overall structure is logical. However, the lack of proper line breaks and indentation creates a tangled presentation that obscures the code's actual simplicity. The code would be significantly more readable with standard formatting conventions.
Run 2
The code is functional but has poor readability due to severe formatting issues. Multiple statements are compressed onto single lines, including imports, method signatures, static initializers, and control flow blocks. The static initializer block (lines 10-13) is particularly difficult to parse because declaration, mutation, and assignment all share one line. The `properties()` method mixes map operations and conditional logic on single lines without vertical separation. Comments and Javadoc are present but interspersed with code, disrupting flow. While the class has a clear purpose and uses meaningful names, the dense formatting obscures intent and makes the logic harder to follow. Proper line breaks and indentation would significantly improve readability.
Run 3
The code is difficult to read due to severe formatting issues. Multiple statements are crammed onto single lines, violating the 'one action per line' principle and disrupting natural reading flow. Package/import statements are on the same line, static initialization and method signatures are compressed, and opening braces are misplaced. The nesting is relatively flat, and the underlying logic is not inherently complex, but the intent is obscured by poor layout. While the class structure and comments are reasonable, the presentation significantly undermines readability. Applying standard formatting and line breaks would dramatically improve understandability.
Run 1
Code Structure: Conventional class organization separates defaults, construction, configuration, and utility methods, but compressed formatting obscures boundaries. Nesting: Mostly shallow; the conditional containing try/catch remains manageable. Clarity of intent: Descriptive names, Javadoc, and the override-precedence comment explain configuration behavior, though overflow handling is not explicitly documented. Code length: Reasonably concise with little unnecessary logic, but extreme line compression hurts readability rather than simplifying it. Action granularity: Multiple imports, assignments, conditionals, annotations, and closing braces share lines, making individual actions harder to identify. Reading flow: Logical execution order is undermined by inconsistent line breaks and crowded method transitions, especially in static initialization and equals.
Run 2
1. Code Structure: The class has logically separated initialization, configuration, and standard object methods, but compressed formatting obscures boundaries. 2. Nesting: Generally shallow; the conditional containing try/catch is manageable. 3. Clarity of intent: Descriptive names, documentation, and the configuration precedence comment clearly explain behavior, including retention overflow handling. 4. Code length: Appropriately concise for its responsibilities, though long lines reduce readability rather than meaningfully simplifying the code. 5. Action granularity: Multiple imports, assignments, conditionals, annotations, and closing braces share lines, making individual operations difficult to scan. 6. Reading flow: Method ordering is natural, but inconsistent line breaks and indentation interrupt the flow, especially in the static initializer, properties method, and equals method.
Run 3
Code Structure: Conventional class organization separates initialization, configuration, and object methods, but compressed formatting obscures boundaries. Nesting: Mostly shallow; the conditional containing try/catch is manageable. Clarity of intent: Descriptive names, documentation, and the precedence comment explain configuration merging and retention handling well. Code length: Appropriately concise for its responsibilities, though long physical lines hinder scanning. Action granularity: Multiple imports, assignments, conditionals, annotations, and method boundaries share lines, significantly reducing readability. Reading flow: Logic follows a natural sequence, but inconsistent line breaks and crowded braces interrupt it. Standard formatting and one statement per line would substantially improve readability.