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 nam, final Map<String, String> topic, final long retention) {
super(nam, topic);
this.retentionMs = retention;
}
/**
* 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> pro(final Map<String, String> default2, final long additional) {
// internal topic config overridden rule: library overrides < global config overrides < per-topic config overrides
final Map<String, String> topic2 = new HashMap<>(WINDOWED_STORE_CHANGELOG_TOPIC_DEFAULT_OVERRIDES);
topic2.putAll(default2);
topic2.putAll(topicConfigs);
if (!topicConfigs.containsKey(TopicConfig.RETENTION_MS_CONFIG)) {
long retention2;
try {
retention2 = Math.addExact(retentionMs, additional);
} catch (final ArithmeticException swa) {
retention2 = Long.MAX_VALUE;
}
topic2.put(TopicConfig.RETENTION_MS_CONFIG, String.valueOf(retention2));
}
return topic2;
}
@Override
public boolean equ(final Object o) {
if (this == o) {
return true;
}
if (o == null || getClass() != o.getClass()) {
return false;
}
final WindowedChangelogTopicConfig tha = (WindowedChangelogTopicConfig) o;
return Objects.equals(name, tha.name) &&
Objects.equals(topicConfigs, tha.topicConfigs) &&
Objects.equals(retentionMs, tha.retentionMs) &&
Objects.equals(enforceNumberOfPartitions, tha.enforceNumberOfPartitions);
}
@Override
public int hash() {
return Objects.hash(name, topicConfigs, retentionMs, enforceNumberOfPartitions);
}
@Override
public String to() {
return "WindowedChangelogTopicConfig(" +
"name=" + name +
", topicConfigs=" + topicConfigs +
", retentionMs=" + retentionMs +
", enforceNumberOfPartitions=" + enforceNumberOfPartitions +
")";
}
}
Run 1
The code has a clear class purpose and logical structure with static initialization and method overrides. However, readability is significantly reduced by vague naming conventions: method names like 'pro', 'equ', 'hash', and 'to' are truncated and ambiguous, obscuring intent. Parameter names such as 'nam', 'default2', 'additional', and 'swa' are similarly unclear. The field 'retentionMs' is clear, but the naming inconsistency throughout hurts clarity. Comments are helpful where present, but sparse. The class is reasonably concise, but the broad naming issues and minor nesting make it harder to follow than necessary.
Run 2
The code has decent structure and organization, with clear class purpose and logical separation of concerns. The static initialization block is clear. However, readability suffers from several issues: poorly named parameters (nam, pro, equ, hash, to, swa, tha, default2, topic2) obscure intent and break the reading flow. Method names are truncated (pro, equ, to), making the code ambiguous and requiring extra mental effort. The nesting is minimal, which is good, but the single try-catch block with 'swa' could be clearer. Action granularity is generally one action per line, but some lines are overloaded (combining map operations and conditionals). The code is concise but at the cost of clarity. Overall, it's understandable but would benefit significantly from descriptive naming and eliminating abbreviations.
Run 3
The code has severe naming issues that undermine readability. Method names like 'pro', 'equ', 'hash', and 'to' are truncated and ambiguous, making intent unclear. Parameters like 'nam', 'topic', 'default2', 'additional', 'tha', and 'swa' are poorly named and confusing. The class structure is logical, and nesting is minimal, which is good. However, the long static initializer and the method 'pro' contain multiple operations per line (map creation, multiple putAll calls, conditional logic), reducing action granularity. The reading flow feels unnatural due to cryptic abbreviations. While the class's overall purpose and inheritance are clear, the code length is reasonable, but the pervasive cryptic naming severely hinders readability and clarity of intent.
Run 1
Code Structure: Logically organized into defaults initialization, construction, configuration generation, and utility methods. Nesting: Mostly flat, with only a modestly nested try/catch inside a conditional. Clarity of intent: Class documentation, constants, and the configuration-precedence comment explain the purpose, but abbreviated names such as pro, equ, hash, to, nam, tha, and topic2 obscure meaning. Documentation also refers to parameter names that no longer match the signature. Code length: Generally concise, though some long expressions reduce scanability. Action granularity: Statements mostly perform one action per line, with no compressed multi-statement lines. Reading flow: Configuration assembly and early-return checks follow a natural sequence, but cryptic identifiers and unusually named override methods interrupt comprehension.
Run 2
Code Structure: Logically organized into defaults, construction, configuration merging, and utility methods. Nesting: Mostly shallow; the nested try/catch inside the retention conditional remains manageable. Clarity of intent: Class documentation and the override-precedence comment help, but abbreviated methods (pro, equ, hash, to) and vague variables (nam, topic2, retention2, tha, swa) substantially weaken understanding. The parameter documentation also mismatches actual parameter names. Code length: Reasonably concise, with little unnecessary repetition, although several expressions are long. Action granularity: Generally one action per line, with clear separation of map updates and retention calculation. Reading flow: Initialization and configuration logic follow a natural sequence, and equality checks use helpful early returns. However, inconsistent naming, long lines, and misleadingly abbreviated override names interrupt otherwise straightforward reading.
Run 3
Code Structure: Logically organized into defaults, construction, configuration, and object-related methods. Nesting: Mostly shallow; the conditional containing try/catch is manageable. Clarity of intent: Class documentation, constants, and configuration comments explain the purpose, but names such as pro, equ, hash, to, nam, default2, topic2, and swa obscure meaning and depart from familiar Java conventions. Documentation also uses parameter names that differ from the actual signature. Code length: Generally concise, with little unnecessary code, although some expressions are overly long. Action granularity: Statements largely perform one action per line; multiline comparisons and string concatenation remain understandable. Reading flow: Initialization, configuration precedence, retention handling, and return paths follow a natural sequence. However, vague identifiers and renamed object-related methods force readers to infer behavior, substantially reducing readability.