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 a, final Map<String, String> b, final long c) {
super(a, b);
this.retentionMs = c;
}
/**
* 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> a(final Map<String, String> d, final long e) {
// internal topic config overridden rule: library overrides < global config overrides < per-topic config overrides
final Map<String, String> f = new HashMap<>(WINDOWED_STORE_CHANGELOG_TOPIC_DEFAULT_OVERRIDES);
f.putAll(d);
f.putAll(topicConfigs);
if (!topicConfigs.containsKey(TopicConfig.RETENTION_MS_CONFIG)) {
long g;
try {
g = Math.addExact(retentionMs, e);
} catch (final ArithmeticException h) {
g = Long.MAX_VALUE;
}
f.put(TopicConfig.RETENTION_MS_CONFIG, String.valueOf(g));
}
return f;
}
@Override
public boolean b(final Object i) {
if (this == i) {
return true;
}
if (i == null || getClass() != i.getClass()) {
return false;
}
final WindowedChangelogTopicConfig j = (WindowedChangelogTopicConfig) i;
return Objects.equals(name, j.name) &&
Objects.equals(topicConfigs, j.topicConfigs) &&
Objects.equals(retentionMs, j.retentionMs) &&
Objects.equals(enforceNumberOfPartitions, j.enforceNumberOfPartitions);
}
@Override
public int c() {
return Objects.hash(name, topicConfigs, retentionMs, enforceNumberOfPartitions);
}
@Override
public String d() {
return "WindowedChangelogTopicConfig(" +
"name=" + name +
", topicConfigs=" + topicConfigs +
", retentionMs=" + retentionMs +
", enforceNumberOfPartitions=" + enforceNumberOfPartitions +
")";
}
}
Run 1
The code has a clear class purpose and logical structure, but readability is severely undermined by meaningless parameter and variable names (e.g., 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h'). This makes the intent ambiguous and forces readers to infer meaning solely from context. The constructor and methods are concise, and nesting is shallow, which is good. However, the disorganized naming disrupts the reading flow and violates clarity of intent. Action granularity is mostly one action per line, but the retention calculation block is slightly dense. The static initializer is straightforward but could be improved with a comment. Overall, the code is maintainable in structure but fails in readability due to obfuscated identifiers.
Run 2
The code structure is logical but suffers from severely obfuscated identifiers (single letters like 'a', 'b', 'c', 'd', 'e', 'f', 'g'), which hurts clarity of intent and reading flow. The method that should be `getProperties` is named 'a', making the code ambiguous despite comments explaining behavior. Nesting is minimal, and action granularity is acceptable. The static initialization block is clear. However, the overridden equals/hashCode/toString methods use placeholder names instead of semantic ones. The retention logic is straightforward but hidden behind opaque naming. Concise code length is fine, but the lack of meaningful names undermines readability significantly.
Run 3
The code structure is logical, but readability is severely degraded by obfuscated naming. Method names like 'a', 'b', 'c', 'd' and single-letter parameters ('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j') completely erase the intent of the code. This makes it extremely difficult to understand what each method does without deep analysis. The nesting is shallow and the action granularity is acceptable, but the lack of meaningful names forces the reader to infer behavior from context. The comments are helpful but cannot compensate for opaque identifiers. This appears to be code that has been deliberately minified or auto-obfuscated, not human-written production code. It would fail most code review standards.
Run 1
Code Structure: Well organized into default initialization, construction, configuration, and object-related methods. Nesting: Mostly flat, with only a modestly nested try/catch inside a conditional. Clarity of intent: Descriptive class and constant names and helpful comments explain the configuration logic, but single-letter method names, parameters, and local variables significantly obscure meaning. Documentation also references additionalRetentionMs while the actual parameter is named e. Code length: Reasonably concise, though several long expressions could be wrapped for easier scanning. Action granularity: Generally one action per line, with compound expressions limited to comparisons, configuration values, and string construction. Reading flow: Configuration precedence and early returns provide a natural sequence, but readers must repeatedly infer what abbreviated identifiers represent.
Run 2
Code Structure: Logically organized into default initialization, construction, configuration merging, and object-style methods. Nesting: Mostly flat, with only a modest if/try-catch combination. Clarity of intent: Class names, constants, and comments explain the domain, but single-letter method names and parameters severely obscure behavior; documentation also references a parameter name absent from the signature. Code length: Generally concise, though long expressions reduce scanability. Action granularity: Statements largely perform one action per line, with readable multiline comparisons and string construction. Reading flow: Configuration precedence and early returns are easy to follow, but readers must repeatedly infer the meanings of anonymous variables and methods.
Run 3
Code Structure: Logically organized into default initialization, construction, configuration merging, and object-style methods. Nesting: Shallow overall; the nested try/catch within a conditional is easy to follow. Clarity of intent: Class names, constants, and comments explain the purpose, but single-letter method names and parameters significantly obscure behavior. Object-style methods must be inferred from their bodies, and documentation uses parameter names absent from the signatures. Code length: Appropriately concise, although some long expressions reduce scanability. Action granularity: Statements generally perform one action per line; multiline comparisons and string concatenation remain coherent. Reading flow: Configuration precedence and early returns provide a natural flow, but cryptic identifiers repeatedly force readers to reconstruct meaning.