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 purpose and minimal nesting. Each method is documented with concise Javadoc, making the intent unambiguous. The reading flow is natural, grouping related methods logically. Action granularity is appropriate — one operation per method signature. The code length is concise and avoids unnecessary verbosity. Minor deductions: some method names (e.g., 'enforceRestoreActive', 'transitToUpdateStandby') could be slightly clearer, and the interface mixes state-transition, query, and cleanup responsibilities, which slightly impacts structural cohesion. Overall, highly readable.
Run 3
The code is highly readable. The interface is logically organized with clear method groupings. Javadoc comments effectively clarify intent, especially for methods with complex return semantics. The methods are well-named, follow Java conventions, and are concise with one action per declaration. The overall structure flows naturally, making the purpose of the ChangelogReader contract easy to understand.
Run 1
Code Structure: A well-organized interface groups related changelog operations, with documentation immediately preceding each declaration. Nesting: Entirely flat, with no nested control flow. Clarity of intent: Descriptive method names, explicit return types, and Javadocs make the API understandable; however, 'transit' is awkward terminology, and the distinction between clear(), isEmpty(), and initialization could be clearer. Code length: Concise declarations with mostly useful documentation; allChangelogsCompleted() repeats some information. Action granularity: Each method declaration occupies its own line and represents a distinct operation. Reading flow: Consistent spacing and documentation create a natural progression from restoration and mode switching to status queries and cleanup. Minor weaknesses include missing separation after the package declaration, mixed import grouping, and slightly imprecise wording in several comments.
Run 2
Code Structure: A well-organized interface groups restoration, mode switching, status queries, and cleanup methods logically. Nesting: No nested control flow; declarations are flat and easy to scan. Clarity of intent: Descriptive method names, typed signatures, and Javadoc explain responsibilities and return values. Minor wording issues such as 'Transit' and the distinction between completion-related queries slightly reduce clarity. Code length: Concise declarations with proportionate documentation, though the completion explanation is somewhat repetitive. Action granularity: Each declaration occupies its own line and expresses a single operation or query. Reading flow: Consistent formatting and method spacing support natural reading; separating the package declaration and import groups with blank lines would improve presentation.
Run 3
Code Structure: A focused interface logically groups restoration, mode switching, status queries, and cleanup. Nesting: Flat method declarations with no nested logic make scanning easy. Clarity of intent: Descriptive method names, explicit types, and Javadoc explain responsibilities; slightly awkward wording such as 'Transit to' and domain-specific terminology reduce clarity modestly. Code length: Concise declarations and mostly useful documentation, though the completion description is somewhat repetitive. Action granularity: Each declaration occupies its own line and represents a single operation or query. Reading flow: Consistent formatting and spacing support a natural progression through the API, although grouping imports and making mode-switch naming more consistent would improve polish.