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. It has a clear structure as an interface with logically grouped method declarations, each preceded by concise Javadoc comments. There is no nesting or complex logic, and the intent of each method is unambiguous. The code is appropriately concise—no unnecessary lines or excessive verbosity. Each method signature stands alone, making action granularity clear. The reading flow is natural, with methods ordered logically and comments providing context. Minor deductions: the Javadoc could be slightly more consistent in formatting, and some method names, while descriptive, are long. Overall, this is an excellent example of clean, maintainable interface design.
Run 3
The code is highly readable with a clear interface definition and well-documented methods. Structure is logical: imports, interface declaration, then methods grouped by related functionality. Nesting is non-existent since it's an interface. Intent is clear from descriptive method names and Javadoc comments. Code length is concise—no unnecessary methods or parameters. Action granularity is excellent with single-purpose methods. Reading flow is natural, following a logical progression from restoration to state checking to cleanup. Minor deductions: could optionally add a class-level @since annotation and some methods lack parameter documentation in Javadoc, but overall this is exemplary readable code.
Run 1
Code Structure: A focused interface logically groups restoration, mode switching, progress queries, and lifecycle operations. Nesting: Flat method declarations introduce no control-flow nesting. Clarity of intent: Descriptive method names, explicit types, and Javadoc make the contract clear, although 'Transit' is awkward wording and logical end-offset semantics could be explained more precisely. Code length: Concise overall; the longer completion documentation usefully explains standby behavior. Action granularity: Each declaration occupies its own line and represents one operation. Reading flow: Consistent spacing and documentation support easy scanning, though separating the package declaration and import groups would improve presentation.
Run 2
Code Structure: A cohesive interface with logically grouped restoration, status, and cleanup methods. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive method names, explicit types, and Javadoc make responsibilities clear, though phrases such as 'Transit to' and 'logical changelog partitions end-offsets' could be clearer. Code length: Concise method signatures with useful documentation; the longer completion explanation clarifies an important standby-task constraint. Action granularity: Each declaration occupies its own line and represents a single operation or query. Reading flow: Consistent formatting and documentation support natural scanning, although separating the package declaration and import groups with blank lines would improve presentation.
Run 3
Code Structure: A focused interface groups related changelog restoration, mode control, status, and cleanup operations logically. Nesting: Flat method declarations introduce no nested control flow. Clarity of intent: Descriptive method names, explicit types, and Javadoc make responsibilities clear; slightly awkward wording such as 'Transit' and 'logical changelog partitions end-offsets' reduces precision. Code length: Concise declarations with useful documentation, though the completion documentation repeats some information. Action granularity: Each declaration represents a single operation and occupies its own line. Reading flow: Consistent formatting and progression from restoration to status and cleanup support easy scanning; spacing between the package and import groups would improve presentation.