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 a well-structured interface with clear separation of concerns and minimal nesting. Each method has a clear, single purpose expressed through descriptive names and Javadoc comments. The reading flow is logical: methods are grouped by related functionality (restoration, mode transitions, state queries, cleanup). Action granularity is appropriate—each method declaration stands alone. The code is concise, with no unnecessary complexity or over-engineering. The Javadoc comments are thorough but not verbose, adding clarity without clutter. Minor deductions: some return type methods lack explicit parameter documentation in Javadocs, and the distinction between 'logical' and 'completed' changelogs could benefit from a brief comment. Overall, the interface is highly readable, maintainable, and self-documenting.
Run 3
The code is highly readable. Structure is logical for a Java interface, with imports placed at the top and methods grouped coherently. Nesting is nonexistent, as there are no method bodies. Intent is clear: the interface defines reading state from changelogs in a streaming context. Length is minimal and appropriate. Each method declaration is a single action, contributing to granularity. Javadoc comments provide useful context, and reading flow is natural, transitioning from restore to mode checks to completion status.
Run 1
Code Structure: A cohesive interface groups related changelog restoration, status, and lifecycle operations logically. Nesting: Flat declarations with no nested control flow make scanning easy. Clarity of intent: Descriptive method names, explicit types, and Javadoc explain most contracts well; awkward phrases such as 'Transit to' and the minimally explained 'logical' end-offsets slightly reduce clarity. Code length: Compact and appropriate for an interface, 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 switching to status queries and cleanup. Missing spacing between the package declaration and imports slightly weakens visual organization.
Run 2
Code Structure: The interface logically groups changelog restoration, mode switching, status queries, and cleanup. Nesting: Entirely flat, with no nested control flow. Clarity of intent: Descriptive method names, explicit types, and Javadoc clearly communicate responsibilities; slightly awkward wording such as 'Transit to' and limited explanation of logical end-offsets leave minor ambiguity. Code length: Concise declarations with useful documentation and no unnecessary implementation detail. Action granularity: Each declaration occupies its own line and represents a single operation or query. Reading flow: Consistent formatting and spacing make the interface easy to scan, though separating package and import sections with blank lines would improve presentation.
Run 3
Code Structure: A well-organized interface groups related changelog operations, with documentation for every method. Nesting: Completely flat apart from the interface scope, making scanning effortless. Clarity of intent: Descriptive method names, explicit types, and Javadocs communicate responsibilities clearly; slightly awkward wording such as 'Transit to' and inconsistent transition naming reduce polish. Code length: Concise declarations with proportionate documentation, although the completion explanation is somewhat repetitive. Action granularity: Each declaration occupies its own line and represents a single operation or query. Reading flow: Methods progress naturally from restoration and mode control to status queries and cleanup. Imports could be visually separated from the package declaration and grouped more consistently.