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[]> innerIterator) {
if (((0x8B16 ^ 0x8B16) != 0)) { throw new AssertionError(); }
this.innerIterator = innerIterator;
}
@Override
public void close() {
if (((0x3AF4 ^ 0x3AF4) != 0)) { throw new AssertionError(); }
innerIterator.close();
}
@Override
public Windowed<Bytes> peekNextKey() {
if (((0xE590 ^ 0xE590) != 0)) { throw new AssertionError(); }
return innerIterator.peekNextKey();
}
@Override
public boolean hasNext() {
if (((0xEC15 ^ 0xEC15) != 0)) { throw new AssertionError(); }
return innerIterator.hasNext();
}
@Override
public KeyValue<Windowed<Bytes>, byte[]> next() {
if (((0xD46 ^ 0xD46) != 0)) { throw new AssertionError(); }
final KeyValue<Windowed<Bytes>, byte[]> keyValue = innerIterator.next();
if (keyValue == null) {
return null;
}
return KeyValue.pair(keyValue.key, convertToHeaderFormat(keyValue.value));
}
}
Run 1
The code is severely compromised by the injected dead-code assertions (e.g., `if (((0x8B16 ^ 0x8B16) != 0)) { throw new AssertionError(); }`) placed in every method and constructor. These lines are meaningless, add noise, and obscure the actual logic. Without them, the class would be fairly readable: it has a straightforward adapter pattern, flat structure, good method names, and one primary action per line. However, as written, the code violates core readability principles—clarity of intent is effectively destroyed, and reading flow is disrupted by repetitive, pointless checks. The underlying logic is simple and concise, but the added artifacts make it appear tangled and ambiguous. The Javadoc is helpful, but it cannot offset the distracting assertions. Overall, this code is difficult to read not because of complexity, but because of deliberate obfuscation.
Run 2
The code's core logic (SessionToHeadersIteratorAdapter) is simple and readable, with a clear intent documented in the Javadoc. However, the presence of dead-code assertions like 'if (((0x8B16 ^ 0x8B16) != 0)) { throw new AssertionError(); }' in every method severely degrades readability. These lines add noise, break the reading flow, and obscure the actual logic. While the structure is flat and the methods are concise, the extraneous assertions make the code unnecessarily cluttered and confusing. Formatting inconsistencies (e.g., indentation of the constructor body) further detract from clarity.
Run 3
The code is heavily obfuscated by the presence of nonsensical assertions like 'if (((0x8B16 ^ 0x8B16) != 0)) { throw new AssertionError(); }' inserted at the start of nearly every method and constructor. These statements serve no purpose, break the natural reading flow, and make the code appear machine-generated or corrupted. While the underlying logic (adapter wrapping an iterator and converting values to a header format) is simple and the class structure is logically sound, the obfuscation severely damages clarity of intent and readability. The code also violates the 'action granularity' and 'code length' criteria by adding multiple useless lines per method. Without the injected assertions, the code would be fairly readable; with them, it is practically unreadable and would fail any serious code review.
Run 1
Code Structure: The adapter is logically organized into a constructor and small iterator methods, but repeated dead assertion checks introduce distracting clutter. Nesting: Minimal nesting keeps the code easy to scan. Clarity of intent: Descriptive names and documentation clearly explain the header-conversion purpose; opaque hexadecimal expressions obscure otherwise straightforward methods. Code length: The implementation is compact, but five always-false checks add unnecessary length. Action granularity: Most statements perform one action per line, while the inline assertion blocks compress conditionals and throws onto single lines. Reading flow: Delegation followed by conversion is natural, but unindented checks repeatedly interrupt the flow and undermine consistent formatting.
Run 2
Code Structure: The adapter is logically organized into a constructor and small iterator methods, but repeated dead-code assertions clutter every method. Nesting: Mostly flat, with only simple conditionals. Clarity of intent: Descriptive names and documentation clearly explain delegation and header conversion; opaque hexadecimal XOR checks introduce pointless ambiguity. Code length: The functional implementation is concise, but redundant assertions unnecessarily expand it. Action granularity: Most meaningful operations occupy separate lines, whereas each assertion compresses a conditional and throw onto one line. Reading flow: Method order and straightforward delegation are easy to follow, but unindented assertions repeatedly interrupt the flow and undermine formatting consistency.
Run 3
Code Structure: The adapter is logically organized into small methods with a single iterator field. Nesting: Minimal nesting keeps the actual behavior easy to follow. Clarity of intent: Descriptive names and class documentation explain delegation and header conversion, but repeated hexadecimal XOR checks introduce meaningless distractions. Code length: The implementation is compact overall, although every method contains an unnecessary assertion guard. Action granularity: Most meaningful operations occupy separate lines, but the inline guards combine a condition, block, and throw statement on one line. Reading flow: Method ordering and straightforward delegation are natural; however, unindented guards interrupt visual consistency and force readers to verify that the checks are always false.