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[]> a) {
this.innerIterator = a;
}
@Override
public void a() {
innerIterator.close();
}
@Override
public Windowed<Bytes> b() {
return innerIterator.peekNextKey();
}
@Override
public boolean c() {
return innerIterator.hasNext();
}
@Override
public KeyValue<Windowed<Bytes>, byte[]> d() {
final KeyValue<Windowed<Bytes>, byte[]> b = innerIterator.next();
if (b == null) {
return null;
}
return KeyValue.pair(b.key, convertToHeaderFormat(b.value));
}
}
Run 1
The code is poorly structured and confusing. Method names (a, b, c, d) and parameter name (a, b) are completely meaningless, obscuring the adapter's purpose. The single override (d) has nested calls and conditionals, reducing clarity. While the class-level Javadoc explains intent, the implementation breaks readability. The code is concise but at the expense of clarity. The import of convertToHeaderFormat is used correctly, but the overall flow is disjointed. Multiple logical actions are compressed into a single line (return KeyValue.pair(...)), violating action granularity. Nesting is minimal but method naming and lack of meaningful identifiers ruin natural reading flow.
Run 2
The code is heavily obfuscated despite its clear Javadoc. Method names like a(), b(), c(), and d() completely obscure intent, violating the 'clarity of intent' criterion. The parameter named 'a' and local variable 'b' also hide meaning. The adapter pattern structure is logical, but the obfuscated names negate any structural clarity. Nesting is minimal and reading flow is disrupted only by meaningless identifiers. Code length is reasonable and action granularity is acceptable, but the core purpose of each method requires guesswork. The class would be readable if method names were close(), peekNextKey(), hasNext(), and next() respectively. As written, it ranks very poorly for maintainability despite the clean structure.
Run 3
The code structure is mostly clear with a single adapter class and a simple delegate pattern. However, it loses points for several issues: method names like 'a()', 'b()', 'c()', 'd()' are completely meaningless and obscure intent; the parameter name 'a' in the constructor is also poor; variable 'b' in method 'd()' conflicts with method 'b()' creating confusion. Nesting is flat and flow is natural, but the obfuscated names significantly harm clarity. The code is concise and has one action per line, which is positive. The Javadoc is helpful for understanding the purpose. Overall, the logic would be readable if properly named, but currently requires mental mapping between meaningless names and their actual functions.
Run 1
Code Structure: The adapter is logically organized, with one wrapped iterator and small delegation methods. Nesting: Only a single conditional appears, making control flow easy to follow. Clarity of intent: The class name and documentation explain the compatibility purpose, but method names a(), b(), c(), and d(), along with variables a and b, obscure their roles and do not match the expected iterator interface methods. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one clear action. Reading flow: Constructor, delegation methods, and value conversion form a natural sequence, although cryptic naming and tightly grouped imports reduce readability.
Run 2
Code Structure: A small, logically organized adapter with a single responsibility and straightforward delegation. Nesting: Minimal; only one simple null check. Clarity of intent: Class documentation and innerIterator explain the overall purpose, but method names a(), b(), c(), and d(), plus variables a and b, obscure individual operations. These method names also do not match the expected KeyValueIterator methods despite @Override annotations, creating confusion about correctness. Code length: Concise, without unnecessary implementation detail. Action granularity: Each statement performs one clear action. Reading flow: Delegation followed by conversion is easy to follow, though cryptic naming and tightly grouped imports reduce readability.
Run 3
Code Structure: A small, logically organized adapter with a single responsibility and straightforward delegation. Nesting: Minimal; only one shallow null check. Clarity of intent: Class documentation and innerIterator explain the overall purpose, but method names a, b, c, and d and variable names a and b obscure individual operations. These method names also do not match the expected KeyValueIterator interface methods, making the overrides confusing. Code length: Concise without unnecessary logic. Action granularity: Each statement performs one clear action. Reading flow: Delegation followed by value conversion is natural, although cryptic naming and tightly packed imports reduce readability.