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 a,
final String b) {
super(a,
Long.MAX_VALUE,
new TimeFirstWindowKeySchema(),
Optional.empty(),
new KeyValueSegments(a, b, Long.MAX_VALUE, Long.MAX_VALUE));
}
@Override
protected KeyValue<Bytes, byte[]> a(final Bytes c, final byte[] d) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
@Override
Map<KeyValueSegment, WriteBatch> b(final Collection<ConsumerRecord<byte[], byte[]>> e) {
return b(
e,
WindowKeySchema::extractStoreTimestamp,
null, // never an indexed store -- not needed
TimeFirstWindowKeySchema::fromNonPrefixWindowKey
);
}
@Override
protected IndexToBaseStoreIterator c(final SegmentIterator<KeyValueSegment> f,
final IsolationLevel g) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
}
Run 1
The code structure is logical but severely undermined by extremely poor naming. Parameters like 'a', 'b', 'c', 'd', 'e', 'f', and 'g' obscure all intent, making the code unreadable despite its short length. Method names 'a', 'b', and 'c' are equally cryptic. Nesting is flat and action granularity is acceptable, but the reading flow is completely broken because the reader cannot discern what any method or parameter does without external context. The class purpose is stated in the Javadoc, but the implementation details are a black box. A developer would need to reverse-engineer the code to understand it, which defeats readability.
Run 2
The code has some structural organization (clear class hierarchy, logical method grouping), but suffers from poor naming conventions. Parameters like 'a', 'b', 'c', 'd', 'e', 'f', 'g' and methods 'a()', 'b()', 'c()' severely obscure intent. This forces readers to infer purpose from context or documentation. The 'b()' method contains a method overload with a null comment that helps somewhat, but the multi-line method call breaks reading flow. Nesting is minimal and action granularity is mostly reasonable. However, the constructor chains parameters without clear meaning at call sites. The unsupported operation methods are clear in intent but the surrounding naming destroys readability. Overall, the code requires significant mental overhead to understand, making it difficult to maintain despite the relatively simple logic.
Run 3
The code is short (just 4 methods) but it is NOT readable. Key issues: (1) the method names are totally meaningless: a(), b(), c(); (2) the parameter names are also meaningless: a, b, c, d, e, f, g; (3) the methods are declared but simply throw UnsupportedOperationException or delegate, which makes the class PURPOSE highly confusing and raises the question of why they are even here; (4) inside method b(), there are TWO calls called 'b' — one is the method itself and one is a call to an overloaded 'b' with 3 args, which creates confusion; (5) the unused argument 'd' in method a() implies design issues. The class inherits from a long class name, and comments are also sparse. Nesting is flat and line count is low, but this is only a skeleton with abstract methods. The overall code reads like decompiled or obfuscated code, which significantly hurts clarity and maintainability.
Run 1
Code Structure: A small, logically organized class with a constructor and clearly separated overrides. Nesting: Very flat, with no nested control flow. Clarity of intent: The descriptive class name, documentation, and exception messages help, but single-letter method and parameter names obscure responsibilities and data meaning. The overloaded b call also requires external context to understand. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one main action, and multiline argument lists aid scanning. Reading flow: The constructor-to-overrides progression is natural, but inconsistent indentation, tightly packed imports, and cryptic identifiers interrupt comprehension. Overall, the simple structure is readable, while poor naming substantially limits understanding.
Run 2
Code Structure: The class is logically organized into a constructor and three overrides, with no tangled logic. Nesting: Very shallow; there are no nested control structures. Clarity of intent: The descriptive class name, documentation, exception messages, and schema references provide context, but single-letter method and parameter names severely obscure individual responsibilities. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear action, and multiline calls separate arguments reasonably well. Reading flow: The constructor-to-overrides sequence is natural, but inconsistent indentation, tightly grouped imports, and the overloaded method named b make scanning and understanding delegation harder.
Run 3
Code Structure: The class is logically organized into a constructor and short overrides, with no tangled logic. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: The class name, documentation, and exception messages convey the overall purpose, but single-letter method and parameter names obscure individual responsibilities. Code length: Concise, with little unnecessary code. Action granularity: Statements perform one action each, and multiline argument lists aid readability. Reading flow: The constructor-to-overrides progression is natural, but inconsistent indentation, tightly packed imports, and opaque names interrupt comprehension.