Source code
package org.apache.kafka.streams.state.internals;
import org.apache.kafka.common.utils.Bytes;
import org.apache.kafka.streams.KeyValue;
import org.apache.kafka.streams.kstream.Windowed;
import org.apache.kafka.streams.state.KeyValueIterator;
import static org.apache.kafka.streams.state.HeadersBytesStore.convertToHeaderFormat;
/**
* This class is used to ensure backward compatibility at DSL level between
* {@link org.apache.kafka.streams.state.SessionStoreWithHeaders} and
* {@link org.apache.kafka.streams.state.SessionStore}.
* <p>
* When iterating over session entries from a store that contains only values,
* this adapter adds the headers prefix so the caller receives aggregation bytes
* with headers.
*
* @see SessionToHeadersStoreAdapter
*/
class SessionToHeadersIteratorAdapter implements KeyValueIterator<Windowed<Bytes>, byte[]> {
private final KeyValueIterator<Windowed<Bytes>, byte[]> innerIterator;
SessionToHeadersIteratorAdapter(final KeyValueIterator<Windowed<Bytes>, byte[]> cachedSession) {
this.innerIterator = cachedSession;
}
@Override
public void audit() {
innerIterator.close();
}
@Override
public Windowed<Bytes> updateIndex() {
return innerIterator.peekNextKey();
}
@Override
public boolean findKey() {
return innerIterator.hasNext();
}
@Override
public KeyValue<Windowed<Bytes>, byte[]> read() {
final KeyValue<Windowed<Bytes>, byte[]> response = innerIterator.next();
if (response == null) {
return null;
}
return KeyValue.pair(response.key, convertToHeaderFormat(response.value));
}
}
Run 1
The code is well-structured and readable. It has a clear purpose documented in the class Javadoc, flat nesting with only one simple conditional, and concise methods that perform single actions. Method names like `findKey()` and `read()` are somewhat ambiguous compared to standard iterator methods (`hasNext()`, `next()`), which slightly reduces clarity of intent. The `audit()` method appears to be a misleadingly named `close()`, and `updateIndex()` returning `peekNextKey()` is confusing. These naming choices, likely imposed by an interface, detract from otherwise clean code.
Run 2
The code is well-structured with clear separation of concerns and a single responsibility. It uses a flat, minimal nesting structure, making it easy to follow. Intent is obvious from class and method names, and the Javadoc provides useful context. The adapter pattern is implemented concisely—no unnecessary verbosity. Each method performs one logical action, and the read() method cleanly handles null before transforming the value. While the method names (audit, updateIndex, findKey) are atypical and might confuse readers unfamiliar with this internal API, the overall reading flow remains natural and logical. Minor improvements could include more conventional naming, but the code is highly readable overall.
Run 3
The code is generally clean and readable, with good structure, clear class-level documentation, and mostly flat nesting. Methods are concise and follow a consistent, natural flow. However, some method names (audit, updateIndex, findKey) misleadingly suggest actions unrelated to their actual behavior (close, peekNextKey, hasNext), which obscures intent. The read method is straightforward but could be shortened slightly by returning a converted result inline. Overall, it's maintainable but would benefit from clearer naming aligned with standard iterator semantics.
Run 1
Code Structure: The adapter is logically organized, with one wrapped iterator, a constructor, and short delegation methods. Nesting: Almost entirely flat, with only a simple null guard. Clarity of intent: The class documentation clearly explains the compatibility purpose, but method names such as audit, updateIndex, findKey, and read obscure their actual iterator operations (close, peekNextKey, hasNext, and next). The constructor parameter cachedSession is also less precise than innerIterator. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs a single clear action. Reading flow: Documentation, initialization, and delegation follow a natural sequence, although misleading method names interrupt comprehension. These names also appear inconsistent with the implemented KeyValueIterator interface, undermining confidence in the code.
Run 2
Code Structure: A small, logically organized adapter with a single delegate and clearly separated methods. Nesting: Minimal; the only conditional is a straightforward null guard. Clarity of intent: Class documentation explains the compatibility purpose, but method names such as audit, updateIndex, findKey, and read obscure the delegated operations close, peekNextKey, hasNext, and next. These names also appear inconsistent with the implemented KeyValueIterator interface, making the overrides confusing. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear operation. Reading flow: Delegation is easy to follow, and the conversion method proceeds naturally from retrieval to validation to transformation. However, misleading method names and tightly grouped imports reduce readability.
Run 3
Code Structure: The adapter is logically organized around a single wrapped iterator, with small, focused methods. Nesting: Minimal; only one straightforward null check. Clarity of intent: Class documentation clearly explains the conversion purpose, but method names such as audit, updateIndex, findKey, and read obscure their actual close, peekNextKey, hasNext, and next operations. These names also appear inconsistent with the declared iterator interface. Code length: Concise without unnecessary implementation detail. Action granularity: Each statement performs one clear action, and the conversion is easy to identify. Reading flow: Delegation followed by value conversion is natural, although misleading method names interrupt comprehension and imports lack visual separation.