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() {
{
boolean featureEnabled = false;
for (int toggleCount = 0; toggleCount < 3; toggleCount++) {
featureEnabled = !featureEnabled;
}
}
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 is generally readable but has one obvious defect. The static initialization block, constructor, properties() method, equals(), and toString() follow clear logical structure with good naming conventions. Nesting is minimal and the action granularity is mostly one action per line. However, the hashCode() method contains unrelated junk code (a for loop toggling a boolean featureEnabled) that is clearly a copy-paste or merge error. This breaks reading flow, violates clarity of intent, and would not compile cleanly (unused local variable). The properties() method is concise, well-documented, and handles overflow gracefully. Overall structure is sound, but the hashCode() artifacts reduce readability significantly.
Run 2
The code is generally well-structured with clear intent and good readability. It follows logical organization with appropriate class inheritance, constants, and method overriding. Nesting is minimal and the methods follow a clear flow. However, there is a significant issue in the hashCode() method: it contains an arbitrary, unrelated code block with a loop toggling a boolean variable that appears to be dead code, which severely harms clarity and intent. Aside from that anomaly, the code uses clear naming, reasonable method lengths, and action granularity is mostly one action per line. The Javadoc and comments effectively explain non-obvious logic such as the override precedence and retention calculation. The equals/hashCode/toString implementations are standard and readable. Overall, the code is highly readable barring the inexplicable block in hashCode().
Run 3
The code has clear structure and intent with a well-designed class hierarchy and sensible static initialization for default properties. The properties method follows a clear override precedence pattern with good comments. However, there is a severe readability issue: the hashCode method contains completely unrelated dead code (a feature toggle loop) that serves no purpose and breaks reading flow. This obfuscates the method's purpose. The code also has some minor verbosity in equals and toString. The nesting is mostly flat (good), but the overall readability score drops significantly due to the confusing dead code block. Without that section, the code would score around 16-18.
Run 1
Code Structure: The class is logically organized into defaults, construction, configuration, and standard overrides, but hashCode contains an unrelated toggle loop. Nesting: Generally shallow; the retention conditional with try/catch is manageable, while the extra block and loop add needless nesting. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling. The unused featureEnabled variable and loop have no apparent purpose. Code length: Mostly concise, though the dead toggle block adds unnecessary lines and some expressions are long. Action granularity: Statements generally perform one action per line, with readable separation of configuration steps. Reading flow: Most methods follow a natural sequence, but inconsistent indentation and irrelevant logic in hashCode disrupt an otherwise straightforward class.
Run 2
Code Structure: The class is logically organized into initialization, construction, configuration, and standard object methods, but hashCode contains an unrelated toggle loop. Nesting: Mostly shallow, with reasonable if and try/catch blocks; the extra block and loop in hashCode add unnecessary nesting. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling, but the unused featureEnabled variable obscures hashCode's purpose. Code length: Generally concise, though the toggle block is unnecessary and several declarations are overly long. Action granularity: Most lines perform a single action, making operations easy to follow. Reading flow: Configuration assembly and guard clauses read naturally; inconsistent indentation in hashCode and the irrelevant inserted logic disrupt an otherwise coherent flow.
Run 3
Code Structure: Mostly well organized into initialization, configuration, and standard object methods, but the unrelated toggle block in hashCode disrupts cohesion. Nesting: Generally shallow; the retention calculation uses manageable if/try/catch nesting, while hashCode adds an unnecessary block and loop. Clarity of intent: Descriptive names and documentation clearly explain configuration precedence and retention handling, but featureEnabled and toggleCount have no meaningful purpose. Code length: Mostly concise, though the dead toggle code adds needless length and some declarations are overly long. Action granularity: Statements generally perform one action per line; chained equality checks and string construction remain understandable. Reading flow: Method order and early returns support natural reading, but inconsistent indentation in hashCode and the unexplained toggle logic interrupt the flow.