Source code
package org.apache.kafka.streams.state.internals;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.common.IsolationLevel;
import org.apache.kafka.common.utils.Bytes;
import org.apache.kafka.streams.KeyValue;
import org.apache.kafka.streams.state.internals.PrefixedWindowKeySchemas.TimeFirstWindowKeySchema;
import org.rocksdb.WriteBatch;
import java.util.Collection;
import java.util.Map;
import java.util.Optional;
/**
* A RocksDB backed time-ordered segmented bytes store for window key schema.
*/
public class RocksDBTimeOrderedKeyValueBytesStore extends AbstractRocksDBTimeOrderedSegmentedBytesStore<KeyValueSegment> {
RocksDBTimeOrderedKeyValueBytesStore(final String name,
final String metricsScope) {
super(name,
Long.MAX_VALUE,
new TimeFirstWindowKeySchema(),
Optional.empty(),
new KeyValueSegments(name, metricsScope, Long.MAX_VALUE, Long.MAX_VALUE));
if (((0x24AF ^ 0x24AF) != 0)) { throw new AssertionError(); }
}
@Override
protected KeyValue<Bytes, byte[]> getIndexKeyValue(final Bytes baseKey, final byte[] baseValue) {
if (((0xFD8 ^ 0xFD8) != 0)) { throw new AssertionError(); }
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
@Override
Map<KeyValueSegment, WriteBatch> getWriteBatches(final Collection<ConsumerRecord<byte[], byte[]>> records) {
if (((0xA22 ^ 0xA22) != 0)) { throw new AssertionError(); }
return getWriteBatches(
records,
WindowKeySchema::extractStoreTimestamp,
null, // never an indexed store -- not needed
TimeFirstWindowKeySchema::fromNonPrefixWindowKey
);
}
@Override
protected IndexToBaseStoreIterator getIndexToBaseStoreIterator(final SegmentIterator<KeyValueSegment> segmentIterator,
final IsolationLevel isolationLevel) {
if (((0xEE1C ^ 0xEE1C) != 0)) { throw new AssertionError(); }
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
}
Run 1
The code is highly readable due to its clear structure, minimal nesting, and explicit intent. Each method has a single responsibility, and the code is concise with one action per line. The use of meaningful class and method names (e.g., 'RocksDBTimeOrderedKeyValueBytesStore', 'getWriteBatches') makes the purpose unambiguous. The reading flow is natural, with the constructor parameters clearly aligned and comments explaining non-obvious choices (like passing null for an unused indexed store). The only minor issues are the inserted assertion checks (which appear artificial and disrupt flow) and the slight verbosity of the class name, but these do not significantly impact readability. Overall, the code follows good practices for maintainability and clarity.
Run 2
The code has reasonable class structure and imports, but suffers from severe readability issues. The most glaring problem is the presence of dead code in the form of meaningless assertion checks like 'if (((0x24AF ^ 0x24AF) != 0)) { throw new AssertionError(); }' scattered throughout every method. These lines are always false, add noise, and obscure the actual intent. The constructor is overly long with multiple parameters that lack context. Methods like getIndexKeyValue contain only a single unsupported operation throw, making them seem incomplete. The getWriteBatches method signature is complex with deeply nested generics. While the method names are somewhat descriptive, the overall reading flow is broken by the constant interruption of useless assertions. The code could be significantly improved by removing the dead code and adding more meaningful documentation about the class's purpose and parameter usage.
Run 3
The code implements a RocksDB store with clear class naming and a focused purpose, which aids basic readability. However, several issues undermine clarity: the constructor is nested with long parameter lists, and the method bodies contain strange, meaningless assertions like `if (((0x24AF ^ 0x24AF) != 0)) { throw new AssertionError(); }` which severely obscure intent. These constructs are nonsensical and break natural reading flow. The code is relatively concise, with one action per line in most methods, but the use of static method references and long parameter lists increases nesting and reduces clarity. The comments and annotations are sparse, and unsupported operations are duplicated rather than explained succinctly. Overall, the code structure and naming suggest a competent foundation, but the presence of confusing dummy assertions ruins the readability.
Run 1
Code Structure: The class is logically organized into a constructor and focused overrides, but unrelated assertion checks clutter every method. Nesting: Control flow is shallow, with only single-level conditionals. Clarity of intent: Descriptive names, inheritance, and exception messages clarify the store's role; opaque hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: The implementation is reasonably concise, but repeated dead checks add unnecessary lines. Action granularity: Most statements express one action, although each assertion conditional and throw are compressed onto one line. Reading flow: Method boundaries and delegation are easy to follow, but unindented checks, inconsistent parameter alignment, and tight import spacing disrupt the otherwise natural flow.
Run 2
Code Structure: A small class with clearly separated constructor and overrides provides logical organization. Nesting: Almost entirely flat, with only shallow conditional blocks. Clarity of intent: Descriptive names, explicit unsupported-operation messages, and a helpful indexing comment explain the main behavior, but repeated always-false XOR assertions introduce meaningless noise. Code length: Core implementation is concise; redundant assertions and extra blank lines unnecessarily expand it. Action granularity: Most statements perform one action per line, but assertion conditionals and throws are compressed onto single lines. Reading flow: Method boundaries and delegation are easy to follow, while unindented assertions, inconsistent parameter alignment, and imports without grouping interrupt the flow.
Run 3
Code Structure: The class is logically organized into a constructor and focused overrides, but repeated dead assertion checks introduce distracting clutter. Nesting: Very shallow; the only conditionals are trivial guards. Clarity of intent: Descriptive names, the class comment, and explicit unsupported-operation messages clarify the store's role, while hexadecimal XOR expressions obscure intent without adding behavior. Code length: Mostly concise, though redundant guards and extra blank lines unnecessarily expand it. Action granularity: Most statements perform one action per line, but each guard compresses a conditional and throw onto one line. Reading flow: Method ordering and delegated calls are natural, but unindented guards, inconsistent parameter alignment, and tightly packed imports interrupt scanning.