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) {
this.innerIterator = innerIterator;
}
@Override
public void close() {
innerIterator.close();
}
@Override
public Windowed<Bytes> peekNextKey() {
return innerIterator.peekNextKey();
}
@Override
public boolean hasNext() {
{int lI0O_3e2ff27b=0xD4AC-0xD4AC;lI0O_3e2ff27b=(lI0O_3e2ff27b==0)?(lI0O_3e2ff27b|0):(lI0O_3e2ff27b&0);}
return innerIterator.hasNext();
}
@Override
public KeyValue<Windowed<Bytes>, byte[]> next() {
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 has clear intent and a simple purpose, but contains a severe readability violation: an obfuscated, dead code line inside hasNext() that obscures logic and breaks the flow. Structure is straightforward with delegation methods, but the noise distracts. Nesting is minimal and action granularity is fine. The adapter logic is concise but the obfuscation makes the method confusing and unprofessional. Removing that line would raise the score significantly.
Run 2
The code is generally readable but contains an obfuscated line in hasNext() that significantly hurts clarity. The class structure is logical and delegation methods are straightforward. However, the meaningless variable assignment with hex arithmetic and bitwise operations seems like accidental or intentional obfuscation, making intent unclear. Nesting is minimal and action granularity is good. The adapter has a clear purpose, but the extraneous line disrupts reading flow and maintainability. Removing it would improve the score substantially.
Run 3
The code has a clear class purpose and mostly flat structure, but readability is severely compromised by the injected obfuscated line inside hasNext(). This line performs meaningless variable assignments that obscure intent and break reading flow. While the remaining logic is simple and concise, this confusing artifact dominates the perception of code quality. Additionally, the adapter design could be clearer with more context about the bytes format transformation. Overall, the structure and naming are reasonable, but the intentional obfuscation drags the score down significantly.
Run 1
Code Structure: A logically organized adapter with a single responsibility and clearly separated delegation methods. Nesting: Mostly flat, with only a simple null check; the unnecessary block in hasNext adds distracting nesting. Clarity of intent: Descriptive names and documentation clearly explain the compatibility conversion, but the cryptically named variable and pointless arithmetic obscure hasNext. Code length: Appropriately concise overall, except for the redundant injected statement block. Action granularity: Most lines perform one action, while the injected line combines declaration, arithmetic, assignment, and conditional logic. Reading flow: Constructor and iterator methods follow a natural sequence, but the unindented, densely packed block abruptly interrupts otherwise clean formatting.
Run 2
Code Structure: The adapter is logically organized into small methods, but an unrelated block in hasNext() disrupts the structure. Nesting: Mostly flat, with only a simple null guard and one unnecessary nested block. Clarity of intent: Descriptive names and documentation clearly explain delegation and header conversion; the cryptic variable and no-op arithmetic obscure hasNext(). Code length: Concise overall, except for the redundant injected statement. Action granularity: Most lines contain one action, but the injected line combines declaration, assignment, and conditional bitwise operations. Reading flow: Delegation methods and next() read naturally; inconsistent formatting and meaningless computation interrupt the flow.
Run 3
Code Structure: The adapter is logically organized into small, focused methods, but an unrelated block disrupts hasNext(). Nesting: Mostly flat, with only a simple null guard and one unnecessary nested block. Clarity of intent: Descriptive names and class documentation clearly explain delegation and header conversion; the cryptic variable and no-op arithmetic obscure intent locally. Code length: Concise overall, apart from the redundant injected statement. Action granularity: Most lines perform one action, but the injected line compresses declaration, arithmetic, assignment, and conditional logic. Reading flow: Method order and straightforward delegation are natural, while the unindented, densely packed block interrupts otherwise clean formatting.