Source code
package org.apache.kafka.clients.consumer.internals.events;
import org.apache.kafka.common.IsolationLevel;
import org.apache.kafka.common.TopicPartition;
import java.util.Objects;
import java.util.OptionalLong;
public class CurrentLagEvent extends CompletableApplicationEvent<OptionalLong> {
private final TopicPartition partition;
private final IsolationLevel isolationLevel;
public CurrentLagEvent(final TopicPartition partition, final IsolationLevel isolationLevel, final long deadlineMs) {
super(Type.CURRENT_LAG, deadlineMs);
this.partition = Objects.requireNonNull(partition);
this.isolationLevel = Objects.requireNonNull(isolationLevel);
}
public TopicPartition partition() {
return partition;
}
public IsolationLevel isolationLevel() {
return isolationLevel;
}
@Override
public String toStringBase() {
return super.toStringBase() + ", partition=" + partition + ", isolationLevel=" + isolationLevel;
}
}
Run 1
The code is highly readable. It follows a clear, logical structure with a single-purpose class that extends a base event. The constructor uses null-checking with Objects.requireNonNull for validation, improving robustness. There is minimal nesting, and the flow is straightforward: field declarations, constructor, getters, and a toString override. Naming is clear and descriptive (e.g., partition, isolationLevel). Code length is concise and proportional to the class's purpose. Each action occupies its own line, aiding readability. The toStringBase method follows a consistent pattern. The only minor drawback is the lack of a class-level Javadoc, which would clarify purpose for future maintainers.
Run 2
This is a clean, well-structured immutable event class. It has a clear purpose: representing a request for the current lag of a partition at a given isolation level. The constructor validates non-null arguments using Objects.requireNonNull, and fields are declared final. Action granularity is good—each line performs one action. There is minimal nesting (only the class and constructor). The code is concise and does not repeat logic. Methods like partition() and isolationLevel() clearly communicate what they return. The toStringBase override is clear and readable. Minor deduction only because of missing Javadoc and slightly compact formatting, but overall it is highly readable.
Run 3
The code is highly readable. It has a clear structure: a single class with fields, a constructor, getters, and a toString method. Nesting is minimal. Intent is explicit from class and method names (e.g., CurrentLagEvent, partition, isolationLevel). The code is concise and avoids unnecessary length. Each logical action, such as field assignment and null checks, is on its own line. Reading flow is natural: fields declared first, then constructor, then accessors, then toString. The only minor deduction is that a short Javadoc on the class or methods could improve intent, but this is negligible.
Run 1
Code Structure: The class is logically organized into fields, constructor, accessors, and a string representation override. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive class, field, and method names clearly communicate the event's purpose; constructor null checks make validation explicit. Code length: The implementation is concise, with no unnecessary logic or duplication. Action granularity: Each statement performs a single clear action. Reading flow: The conventional Java layout makes the code easy to follow. Minor formatting improvements, such as separating the package declaration from imports and wrapping the long constructor signature, would improve readability further.
Run 2
Code Structure: Fields, constructor, accessors, and string representation are logically organized. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive class, field, and method names clearly convey a current-lag event; explicit null checks clarify required inputs. Code length: The class is concise, with no unnecessary logic or duplication. Action granularity: Each statement performs one clear action; the string concatenation is cohesive and easy to follow. Reading flow: The ordering is natural and formatting is consistent. Minor improvements include separating the package declaration from imports and wrapping the long constructor signature.
Run 3
Code Structure: Fields, constructor, accessors, and string representation are logically organized. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive class, field, and method names clearly convey a current-lag event; constructor null checks make requirements explicit. Code length: The class is concise, with no unnecessary logic or duplication. Action granularity: Each statement performs one clear action, and constructor initialization is easy to follow. Reading flow: The conventional top-to-bottom organization supports natural reading. Minor formatting issues, including the lack of spacing between package and imports and relatively long constructor and return lines, slightly reduce readability.