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 well-structured with clear separation of concerns: imports, field declarations, constructor, accessors, and toString override. It is flat with no nested logic. Purpose is unambiguous: a completion event carrying partition and isolation level data. The length is concise with no unnecessary code. Each action (assignment, null check, return) is on its own line. Reading flow is natural, progressing from fields to construction to access. Minor deduction for the long class declaration line and the chained `Objects.requireNonNull` calls reducing slightly the one-action-per-line granularity.
Run 2
The code is well-structured with clear purpose and minimal nesting. Each method performs a single action, and the constructor uses Objects.requireNonNull for validation, which is concise and idiomatic. The class extends a base event class and straightforwardly implements accessor methods and toStringBase. The reading flow is natural: fields, constructor, getters, then toString override. There is slight redundancy in parameter names matching field names (requiring 'this.'), but this remains clear. Overall, the code is highly readable with no unnecessary complexity.
Run 3
The code is highly readable. It has a clear, logical structure with a single class extending a base event type. There is minimal nesting, no conditional logic, and the intent is immediately apparent—representing a current lag query event. The constructor is concise, uses Objects.requireNonNull for validation, and field accessors follow a consistent naming convention. Each action is placed on its own line, and the reading flow is natural. The only minor deduction is the slightly redundant layering of toStringBase, though this aligns with the existing framework pattern.
Run 1
Code Structure: Logically organized into fields, constructor, accessors, and string representation. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive class, field, and method names clearly convey the event's purpose; explicit null checks make requirements apparent. Code length: Concise, with no unnecessary implementation or duplication. Action granularity: Each statement performs one clear action; the string concatenation remains straightforward. Reading flow: Natural top-to-bottom progression with consistent formatting. Minor drawbacks are the long constructor signature and limited spacing around the package and import sections.
Run 2
Code Structure: Logically organized into immutable fields, a constructor, accessors, and a string representation. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive class, field, and method names clearly convey an event requesting current lag for a partition and isolation level; null checks make input requirements explicit. Code length: Concise, with no unnecessary implementation. Action granularity: Each statement performs a focused action; the string concatenation remains straightforward. Reading flow: Natural progression from initialization to access and representation. Minor formatting issues, including the lack of spacing between package and imports and the long constructor signature, slightly reduce readability.
Run 3
Code Structure: Fields, constructor, accessors, and string representation are logically organized. Nesting: Flat methods with no nested control flow make scanning easy. Clarity of intent: Descriptive class, field, and method names clearly convey a current-lag event, while explicit null checks establish required inputs. Code length: Concise, with no unnecessary logic or duplication. Action granularity: Each statement performs one clear action; the string concatenation remains straightforward. Reading flow: Conventional Java ordering supports natural top-to-bottom reading. Minor formatting improvements, such as separating the package declaration from imports and wrapping the long constructor signature, would improve readability further.