Source code
package org.apache.kafka.streams.processor.internals;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.streams.processor.TaskId;
import java.util.Map;
import java.util.Set;
/**
* See {@link StoreChangelogReader}.
*/
public interface ChangelogReader extends ChangelogRegister {
/**
* Restore all registered state stores by reading from their changelogs
*
* @return the total number of records restored in this call
*/
long restore(final Map<TaskId, Task> tasks);
/**
* Transit to restore active changelogs mode
*/
void enforceRestoreActive();
/**
* Transit to update standby changelogs mode
*/
void transitToUpdateStandby();
/**
* @return true if the reader is in restoring active changelog mode;
* false if the reader is in updating standby changelog mode
*/
boolean isRestoringActive();
/**
* @return the changelog partitions that have been completed restoring
*/
Set<TopicPartition> completedChangelogs();
/**
* @return the logical changelog partitions end-offsets
*/
Map<TopicPartition, Long> logicalChangelogEndOffsets();
/**
* Returns whether all changelog partitions were completely read.
*
* Since changelog partitions for standby tasks are never completely read, this method will always return
* {@code false} if the changelog reader registered changelog partitions for standby tasks.
*
* @return {@code true} if all changelog partitions were completely read and no standby changelog partitions are read,
* {@code false} otherwise
*/
boolean allChangelogsCompleted();
/**
* Clear all partitions
*/
void clear();
/**
* @return whether the changelog reader has just been cleared or is uninitialized
*/
boolean isEmpty();
}
Run 1
This interface is highly readable. It follows a logical structure, grouping related methods (restore/completion, state transitions, status checks) cleanly. There is no nesting; the code is entirely flat. Each method's intent is clearly expressed through descriptive names and Javadoc comments, including nuanced behavior like standby changelogs never being fully read. The code is concise—no method implementations clutter the interface, and comments are informative without being verbose. Action granularity is excellent: each method declaration occupies one line within a clear signature. Reading flow is natural, starting with the primary restoration method, then mode transitions, status queries, and cleanup. The only minor deduction is the slight redundancy in some Javadoc, but it does not hinder readability. Overall, this is an exemplary public API interface in terms of clarity and maintainability.
Run 2
The code is highly readable due to its clean structure and clear intent. It defines a focused interface with logically grouped methods, each documented with concise Javadoc comments that explain purpose and edge cases. The package declaration and imports are minimal and appropriate. Nesting is non-existent, as expected for an interface, and method granularity is one action per declaration. The reading flow is natural: methods progress from initialization/restoration states to status checks and cleanup. Minor deductions: the interface name 'ChangelogReader' and some method names could be slightly more descriptive regarding state transitions, and the Javadoc for 'allChangelogsCompleted' is somewhat verbose relative to the overall conciseness.
Run 3
The code is an interface definition with clear, Javadoc-documented methods. Structure is logical and straightforward, with methods grouped by purpose (restoration, state queries, cleanup). Nesting is nonexistent since this is an interface. Intent is well-communicated through descriptive method names and thorough documentation, including edge cases like standby changelog behavior. Length is concise — no unnecessary methods or boilerplate. Each method declaration occupies a single logical line, and the reading flow is natural, moving from lifecycle operations to state queries to cleanup. Minor deductions: the import order and interface-level Javadoc could be slightly more descriptive, and a few one-line method declarations could be spaced for visual clarity, but overall this is highly readable.
Run 1
Code Structure: A well-organized interface groups related changelog operations, with documentation for every method. Nesting: Completely flat apart from the interface scope, making it easy to scan. Clarity of intent: Descriptive method names, explicit types, and Javadocs communicate responsibilities; slightly awkward wording such as 'Transit' and 'completed restoring' reduces polish. Code length: Concise declarations with proportionate documentation, although the allChangelogsCompleted comment repeats some information. Action granularity: Each method declaration occupies its own line and represents a distinct operation. Reading flow: Restoration, mode transitions, status queries, and cleanup follow a generally natural sequence. Missing spacing between the package declaration and imports, plus minor documentation inconsistencies, prevent a perfect score.
Run 2
Code Structure: A well-organized interface groups related changelog operations with consistent declarations and documentation. Nesting: No nested control flow; all methods are at a single level. Clarity of intent: Descriptive method names, explicit types, and Javadoc make the API easy to understand, though 'transit' is awkward wording and some mode-transition semantics remain implicit. Code length: Concise declarations with proportionate documentation; the longer completion explanation usefully clarifies standby behavior. Action granularity: Each declaration occupies its own line and represents one operation or query. Reading flow: Methods progress naturally from restoration and mode management to status queries and cleanup. Minor weaknesses include missing spacing between package and import sections and slightly inconsistent naming of mode-transition methods.
Run 3
Code Structure: A well-organized interface groups related changelog operations, with consistent method declarations and documentation. Nesting: No nested logic, making the code easy to scan. Clarity of intent: Descriptive method names, explicit types, and Javadocs clearly communicate responsibilities; minor awkward wording such as 'Transit to' slightly reduces polish. Code length: Concise declarations with appropriately detailed documentation for the less obvious completion semantics. Action granularity: Each declaration occupies its own line, with no combined operations. Reading flow: Methods progress naturally from restoration and mode transitions to status queries and cleanup. Missing spacing between the package and import groups is a minor formatting weakness.