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);
{int lI0O_bdf48047=0x4F54;lI0O_bdf48047=((lI0O_bdf48047^0x4F54)|0)&-1;if(((lI0O_bdf48047&1)==1)){lI0O_bdf48047^=lI0O_bdf48047;}}
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 a logical class structure and generally clear intent (e.g., the property override rule comment). However, readability is severely undermined by an injected, meaningless obfuscated block of code inside the constructor (the `lI0O_bdf48047` variable manipulation). This breaks action granularity and reading flow completely, as it is unrelated to any legitimate logic. Beyond that, the code is mostly flat and concise, but the presence of such dead code makes it ambiguous and untrustworthy. If that block were removed, the score would be significantly higher, likely around 15-16, based on the otherwise reasonable organization and clarity.
Run 2
The code is generally well-structured and readable. It has clear class hierarchy, meaningful method names, and good documentation. The static initializer is properly formatted, and the properties() method follows a logical flow with clear commenting about config precedence. However, there's a suspicious obfuscated line embedded in the constructor that serves no functional purpose but significantly harms readability and trust. The equals/hashCode/toString methods are standard but somewhat verbose. Overall nesting is flat, actions are mostly granular, and intent is clear aside from the obfuscated line which drops the score considerably.
Run 3
The code generally follows clean structure and naming conventions, but contains a significant artifact: an obfuscated line inside the constructor that appears to be garbage or decompiled code. This severely damages clarity and intent. Otherwise, the class is well-organized with clear static initialization, a straightforward override of properties(), and standard equals/hashCode/toString methods. Nesting is minimal, and the reading flow is mostly logical. However, the unexplained 'lI0O...' line creates a major readability problem, making the code look corrupted. Additionally, the long line for putting the cleanup policy is somewhat unwieldy, and the method properties() has a moderately complex conditional with a try-catch that could use a short comment, though the existing comments help. Overall, the code is only moderately readable due to the suspicious injected line and minor length issues.
Run 1
Code Structure: The class is logically organized into defaults, construction, property calculation, and standard object methods, but an unrelated constructor block disrupts cohesion. Nesting: Most code is shallow; the retention conditional with try/catch is manageable. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling, while the obfuscated variable and pointless bitwise operations obscure intent. Code length: Mostly concise, although the injected block adds unnecessary code and long expressions reduce scanability. Action granularity: Normal statements generally perform one action per line, but the constructor block compresses declarations, assignments, and a conditional onto one line. Reading flow: Conventional method ordering and early returns support natural reading; inconsistent formatting and the unexplained constructor block noticeably interrupt it.
Run 2
1. Code Structure: Well-organized class with distinct initialization, configuration, and standard object methods; the constructor contains an unrelated obfuscated block. 2. Nesting: Mostly shallow, with manageable conditional and try/catch nesting; the injected block adds unnecessary complexity. 3. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling, but cryptic identifiers and pointless bitwise operations obscure the constructor. 4. Code length: Generally concise for its responsibilities, though the obfuscated block is unnecessary and some expressions are long. 5. Action granularity: Most statements perform one action per line; the injected block compresses declarations, assignments, and branching onto a single line. 6. Reading flow: Methods follow a natural order and formatting is mostly consistent, but the unindented constructor block sharply interrupts the flow.
Run 3
1. Code Structure: Well-organized class with distinct initialization, configuration, and standard object methods, but an unrelated constructor block disrupts cohesion. 2. Nesting: Generally shallow; the retention calculation uses manageable if/try/catch nesting, while the injected block adds unnecessary nesting. 3. Clarity of intent: Descriptive names and documentation explain configuration precedence and retention handling. The obfuscated variable and meaningless bitwise operations obscure the constructor's purpose. 4. Code length: Mostly proportionate to functionality, although the injected block is entirely unnecessary and some lines are long. 5. Action granularity: Most statements perform one action per line; the injected block compresses declarations, assignments, and a conditional onto one line. 6. Reading flow: Methods follow a natural sequence, and early returns simplify equals. The unindented, densely packed constructor block abruptly interrupts otherwise consistent formatting and flow.