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
The code is highly readable due to its clean interface definition with clear Javadoc comments explaining each method's purpose, parameters, and return values. The structure is logical with imports, class-level documentation, method declarations, and descriptive comments in a consistent order. Nesting is minimal since this is an interface with no method bodies. Each method has a single responsibility and clear intent, such as 'restore', 'clear', and 'isRestoringActive'. The code is concise with no unnecessary length, and each action is on its own line, following standard Java formatting. Reading flow is natural, grouping related methods and providing return value explanations, especially for complex boolean methods like 'allChangelogsCompleted'.
Run 2
This interface is highly readable. It has a clear, logical structure with well-grouped imports and a succinct class-level JavaDoc referencing the implementation. Each method represents a single, clearly defined action, contributing to minimal nesting and a flat, intuitive organization. The code length is appropriate; no method is unnecessarily verbose. The intent of each operation is explicitly documented, and the JavaDoc comments provide valuable context, especially for methods like allChangelogsCompleted, which clarifies edge-case behavior. The reading flow is natural, moving from restoration state transitions to introspection and cleanup methods. Overall, it exemplifies clean, maintainable API design.
Run 3
This code is highly readable. It is a well-documented Java interface with a clear purpose: defining the contract for a ChangelogReader. The structure is logical, with imports grouped and methods ordered in a cohesive manner. Nesting is non-existent since it's an interface. Each method has a clear, single responsibility and is documented with Javadoc comments explaining intent, parameters, and return values. The code is concise, avoiding unnecessary complexity. Action granularity and reading flow are excellent as each method declaration stands alone with descriptive naming. Minor deductions only because some Javadoc comments could be slightly more detailed, but overall this is exemplary readable code.
Run 1
Code Structure: A well-organized interface groups related changelog operations with consistent documentation. Nesting: No nested control flow, making the declarations easy to scan. Clarity of intent: Descriptive method names, explicit types, and Javadoc communicate responsibilities well, though 'transit' is awkward wording and mode-transition naming is inconsistent. Code length: Concise declarations with mostly useful documentation; the completion explanation is slightly repetitive. Action granularity: Each method declaration occupies its own line and represents a distinct operation. Reading flow: Methods progress naturally from restoration and mode management to status queries and cleanup. Minor weaknesses include missing spacing around the package/import sections and placing isEmpty() after clear() rather than alongside other status queries.
Run 2
Code Structure: A well-organized interface groups related changelog restoration, mode switching, status queries, and cleanup operations. Nesting: Flat declarations with no nested control flow make scanning easy. Clarity of intent: Descriptive method names, explicit types, and Javadoc clearly communicate responsibilities; minor awkward wording such as 'Transit to' slightly reduces polish. Code length: Concise declarations and mostly useful documentation avoid unnecessary complexity, though the completion explanation is somewhat repetitive. Action granularity: Each method declaration occupies its own line and represents a focused operation. Reading flow: Methods follow a natural progression from restoration to mode control, completion information, and cleanup. Import grouping and spacing could be improved slightly.
Run 3
Code Structure: A focused interface groups related changelog operations logically, with clear separation between declarations. Nesting: Flat structure with no nested control flow. Clarity of intent: Descriptive method names, explicit types, and Javadocs explain responsibilities and return values; minor awkward wording such as 'Transit to' slightly reduces polish. Code length: Concise declarations with proportionate documentation, although the completion explanation 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. Import grouping could be improved with blank lines, but overall readability is excellent.