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, logical structure and clear separation of concerns. It defines a focused interface with concise, well-documented methods. The file has minimal nesting (only one level of imports and interface declaration), and each method signature is short and atomic, representing a single action. The Javadoc comments effectively clarify intent without being overly verbose, and the method names are descriptive (e.g., `enforceRestoreActive`, `allChangelogsCompleted`). Reading flow is natural, progressing from general operations to specific state queries. Code length is appropriate for the number of operations defined. Minor deductions: the `logicalChangelogEndOffsets` comment is slightly terse compared to others, and there is no blank line between method groups, but overall it is very clear and maintainable.
Run 3
The code is highly readable. The interface is logically organized, with clear separation between methods and their purposes. Nesting is minimal since it's an interface definition, and each method is concise with a single clear action. Javadoc comments effectively communicate intent, including nuanced behavior in methods like 'allChangelogsCompleted'. The reading flow is natural: method names are descriptive and follow a logical progression from restore operations to state queries. Minor deductions: the import block is slightly cluttered but acceptable, and a few method names (e.g., 'transitToUpdateStandby') could be grammatically smoother. Overall, the code demonstrates strong clarity, appropriate granularity, and professional documentation.
Run 1
Code Structure: A well-organized interface groups related changelog restoration, status, and lifecycle operations. Nesting: Flat declarations with no nested control flow make scanning easy. Clarity of intent: Descriptive method names, typed signatures, and Javadocs clearly communicate purpose; awkward wording such as 'Transit to' and limited explanation of logical end-offsets slightly reduce clarity. Code length: Concise overall, although the allChangelogsCompleted documentation is somewhat repetitive. Action granularity: Each method declaration occupies its own line and represents a distinct operation. Reading flow: Methods progress naturally from restoration and mode transitions to status queries and cleanup. Missing spacing between the package and imports, and inconsistent naming of mode-transition methods, are minor readability weaknesses.
Run 2
Code Structure: A cohesive interface groups related changelog restoration, mode switching, status queries, and cleanup operations. Nesting: Completely flat apart from the interface scope, making it easy to scan. Clarity of intent: Descriptive method names, typed signatures, and Javadoc clearly communicate responsibilities; slightly awkward wording such as 'Transit' and 'logical changelog partitions end-offsets' leaves minor ambiguity. Code length: Concise declarations with appropriately sized documentation; the longer completion comment usefully explains standby behavior. Action granularity: Each method declaration occupies its own line and represents a single operation or query. Reading flow: Methods follow a mostly natural progression from restoration and mode management to progress inspection and cleanup. Missing spacing between the package and imports, and between import groups, slightly reduces visual polish.
Run 3
Code Structure: A focused interface groups related changelog operations logically, with consistent declarations and documentation. Nesting: Flat structure with no nested control flow makes scanning effortless. Clarity of intent: Descriptive method names, explicit types, and Javadocs communicate responsibilities well, though phrases such as 'Transit to' and 'logical changelog partitions end-offsets' could be clearer. Code length: Concise interface declarations; the longer completion documentation usefully explains standby-task behavior. Action granularity: Each declaration occupies its own line and represents one operation. Reading flow: Methods progress naturally from restoration and mode control to status queries and cleanup. Minor improvements include separating package and import sections with blank lines and making mode-transition naming more consistent.