Source code
package org.apache.kafka.coordinator.share;
import org.apache.kafka.server.share.SharePartitionKey;
import org.apache.kafka.timeline.SnapshotRegistry;
import org.apache.kafka.timeline.TimelineHashMap;
import org.apache.kafka.timeline.TimelineLong;
import java.util.Objects;
import java.util.Optional;
public class ShareCoordinatorOffsetsManager {
private final TimelineHashMap<SharePartitionKey, Long> offsets;
private final TimelineLong lastRedundantOffset;
public ShareCoordinatorOffsetsManager(SnapshotRegistry snapshotRegistry) {
Objects.requireNonNull(snapshotRegistry);
offsets = new TimelineHashMap<>(snapshotRegistry, 0);
lastRedundantOffset = new TimelineLong(snapshotRegistry);
lastRedundantOffset.set(Long.MAX_VALUE);
}
public void updateState(SharePartitionKey key, long offset, boolean isDelete) {
lastRedundantOffset.set(Math.min(lastRedundantOffset.get(), offset));
offsets.put(key, offset);
Optional<Long> redundantOffset = findRedundantOffset();
redundantOffset.ifPresent(lastRedundantOffset::set);
if (isDelete) {
offsets.remove(key);
}
}
private Optional<Long> findRedundantOffset() {
if (offsets.isEmpty()) {
return Optional.empty();
}
long soFar = Long.MAX_VALUE;
for (long offset : offsets.values()) {
soFar = Math.min(soFar, offset);
if (soFar == lastRedundantOffset.get()) {
return Optional.of(soFar);
}
}
return Optional.of(soFar);
}
public Optional<Long> lastRedundantOffset() {
long value = lastRedundantOffset.get();
if (value <= 0 || value == Long.MAX_VALUE) {
return Optional.empty();
}
return Optional.of(value);
}
TimelineHashMap<SharePartitionKey, Long> curState() {
return offsets;
}
}
Run 1
The code is generally readable with clear class and method names, appropriate use of generics, and logical method separation. However, several issues reduce readability: excessive blank lines and comment blocks create visual noise and break the reading flow. The updateState method performs multiple actions (setting lastRedundantOffset, updating offsets, finding redundant offset, conditional removal) and would benefit from extraction. The findRedundantOffset method contains a lengthy comment block (14 lines) that disrupts the code logic and should be condensed or moved. The early return optimization in findRedundantOffset is not immediately obvious without the comments, making intent slightly ambiguous. Curly braces are sometimes omitted for single-line if statements, which can reduce clarity. Overall structure is decent, but excessive whitespace, verbose comments, and method complexity prevent higher readability.
Run 2
The code is generally clear and well-structured. It has a logical organization, with a clear separation between state management and offset calculation. Nesting is minimal, and each method has a single responsibility. However, readability is affected by the presence of many empty or comment-only lines (likely Javadoc placeholders), which disrupt the reading flow and make the file look unfinished. Some logic, especially in `updateState`, could be clearer—the ordering of operations and the role of `isDelete` are not immediately obvious. The `findRedundantOffset` method contains a large block of comments that interrupts comprehension without adding value. Naming is mostly good, and the use of `Optional` helps express intent. Overall, the code is readable but would benefit from removing empty comment placeholders and simplifying or clarifying the update logic.
Run 3
The code is logically organized with clear method separation and a simple class structure, but several readability issues hold it back. The import block has excessive blank lines, and multiple comment blocks are empty or overly verbose, adding noise without clarifying intent. The `updateState` method performs multiple actions: updating the redundant offset, putting a key, finding another offset, conditionally deleting the key, and has an unexplained `isDelete` flag, making the flow non-obvious. The `findRedundantOffset` method includes a large block of commented-out code that obscures the actual logic. The early return inside the loop is non-intuitive, and the comparison with `lastRedundantOffset.get()` is subtle. `curState()` returning an internal mutable map breaks encapsulation without explanation. However, the code is flat, reasonably concise, and variable names are generally clear, preventing it from being unreadable.
Run 1
Code Structure: The class is logically organized into state, initialization, updates, calculation, and accessors. Nesting: Shallow control flow and early returns make methods easy to follow. Clarity of intent: Most names communicate purpose, but soFar and curState are vague, and the redundancy rules, sentinel values, and deletion ordering lack explanation. Code length: Executable code is concise, but excessive blank lines unnecessarily inflate the listing. Action granularity: Statements generally perform one action per line; the method reference is compact and understandable. Reading flow: Method order is natural, but large whitespace gaps interrupt scanning, and understanding the early exit requires reasoning about the relationship between stored offsets and lastRedundantOffset.
Run 2
Code Structure: Fields, initialization, updates, calculation, and accessors are logically separated. Nesting: Shallow conditionals and a single loop keep complexity low. Clarity of intent: Most names are descriptive, but soFar is vague, and the sentinel value, early exit, and update-before-delete sequence lack explanations. Code length: Executable code is concise, but excessive blank lines unnecessarily expand the listing. Action granularity: Statements generally perform one action per line, making changes easy to follow. Reading flow: Method organization is natural, but large whitespace gaps interrupt scanning, and understanding the redundant-offset invariant requires inference.
Run 3
Code Structure: Fields, initialization, updates, computation, and accessors are logically separated into small methods. Nesting: Shallow conditionals and a single loop keep control flow easy to follow. Clarity of intent: Class and method names convey offset management, but the sentinel value, early-exit assumption, and computation before deletion lack explanation; 'soFar' and 'curState' are less descriptive. Code length: Executable code is concise, but excessive blank lines unnecessarily expand the listing. Action granularity: Each statement generally performs one clear action, with no crowded multi-statement lines. Reading flow: Method ordering and guard clauses support natural reading, while irregular spacing and missing explanations for subtle state transitions interrupt comprehension.