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);
if (((0x81F5 ^ 0x81F5) != 0)) { throw new AssertionError(); }
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) {
if (((0x1266 ^ 0x1266) != 0)) { throw new AssertionError(); }
// 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 (((0x1D89 ^ 0x1D89) != 0)) { throw new AssertionError(); }
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() {
if (((0xA20A ^ 0xA20A) != 0)) { throw new AssertionError(); }
return Objects.hash(name, topicConfigs, retentionMs, enforceNumberOfPartitions);
}
@Override
public String toString() {
if (((0x71AE ^ 0x71AE) != 0)) { throw new AssertionError(); }
return "WindowedChangelogTopicConfig(" +
"name=" + name +
", topicConfigs=" + topicConfigs +
", retentionMs=" + retentionMs +
", enforceNumberOfPartitions=" + enforceNumberOfPartitions +
")";
}
}
Run 1
The code has reasonable structure with clear method separation and descriptive names, but readability is severely impacted by several issues. The most problematic are the obfuscated assertion checks (e.g., `if (((0x81F5 ^ 0x81F5) != 0)) { throw new AssertionError(); }`) that appear randomly throughout the code—these are cryptic, meaningless, and disrupt reading flow. The static initializer and properties method have acceptable logic, but the exception variable named 'swallow' is unusual. While the class follows a logical organization with clear intent in method names and comments, the excessive blank lines after opening braces and the mysterious XOR-based assertions make the code feel cluttered and unprofessional. Nesting is minimal (good), but action granularity suffers from the unnecessary assertion lines breaking the natural flow. The code would be significantly more readable without the obfuscated lines and with more consistent formatting.
Run 2
The code has reasonable structure and clear intent for a Kafka changelog config class, with Javadocs explaining the retention logic. But it is severely undermined by multiple 'AssertionError' spikes inserted in blocks that serve no purpose, add nesting, and are confusing to a reader. Several methods have these odd duplicate line checks at the top, which disrupts natural reading flow and obscures otherwise straightforward methods like equals, hashCode, toString, and properties. The static initializer and map merging logic are reasonably clear, though the long putAll chain could be refactored. Action granularity is mostly one-per-line, but the injected assertion lines break that. The nesting depth is minimal. Overall, the core logic is readable, but the artificial assertions push the score well below what the base code would otherwise deserve.
Run 3
The code has a clear class purpose and follows standard Java structure, but readability is severely compromised by noise. The numerous `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` lines are meaningless, break reading flow, and add clutter. There are also multiple actions on single lines in `equals` and `hashCode`, reducing action granularity clarity. Nesting is mostly flat, which is good, but the inserted assertion lines disrupt logical organization. The static initializer block is reasonable, though the long line for putting cleanup policy is overly dense. Intent of the retention logic is somewhat clear with comments, but the overall effect of the injected dead code makes the file look obfuscated and untrustworthy. Code length is inflated by unnecessary lines. Reading flow is disorganized due to random assert-like statements before method bodies, making it hard to scan the actual logic. Without those injected lines the code would be moderately readable, perhaps around 14-15, but as presented it falls below acceptable clarity thresholds.
Run 1
Code Structure: The class is logically organized into defaults, construction, configuration, and standard object methods. Nesting: Mostly shallow, with manageable try/catch nesting inside one conditional. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling, but repeated, always-false hexadecimal XOR assertions are distracting and suggest unexplained behavior. Code length: Mostly appropriate, although these redundant assertions add unnecessary code. Action granularity: Most lines perform one action; the inline assertion blocks compress condition checking and throwing onto single lines. Reading flow: The main logic progresses naturally, but unindented assertions interrupt every method, and some long expressions reduce scanability. Removing the assertions and improving line wrapping would substantially improve readability.
Run 2
Code Structure: Logical organization separates defaults, construction, configuration, and standard object methods. Nesting: Mostly flat, with only a modest if/try-catch combination. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling, but repeated always-false hexadecimal XOR assertions introduce confusing, purposeless noise. Code length: Generally concise, though those assertions add unnecessary repetition and some lines are overly long. Action granularity: Most lines perform one action; the inline assertion blocks combine condition checking and throwing on a single line. Reading flow: Method order and configuration updates flow naturally, but unindented assertions repeatedly interrupt that flow and undermine otherwise consistent formatting.
Run 3
Code Structure: Methods and fields are logically organized, with configuration logic separated from standard object methods. Nesting: Mostly shallow; the retention conditional with try/catch remains easy to follow. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling, but repeated hexadecimal XOR checks are meaningless distractions. Code length: Core logic is reasonably concise, though redundant assertion checks add unnecessary length and some lines are overly long. Action granularity: Most lines perform one action, but inline condition-and-throw statements compress multiple elements onto one line. Reading flow: Conventional Java organization supports natural reading, while unindented checks repeatedly interrupt the flow and undermine otherwise consistent formatting.