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 a clear class hierarchy and logical organization. Nesting is minimal, and the class is concise with clear intent. Each method performs a single action, aiding action granularity. The use of Objects.requireNonNull? improves null safety and clarity. The toStringBase method follows a natural reading flow. Minor deductions for lack of comments explaining domain-specific concepts like isolation levels, but overall highly readable.
Run 3
This code is highly readable. The class has a clear, single responsibility and follows a logical structure with fields, constructor, accessors, and a toString method. Nesting is nonexistent, and the flow is natural. Naming is descriptive and consistent with Java conventions. Using Objects.requireNonNull in the constructor clearly signals intent and enforces invariants. The code is concise—no unnecessary boilerplate or duplication. Each line performs a single action, and the toStringBase method cleanly composes the parent representation with subclass-specific fields. Overall, it's easy to understand at a glance, with minimal cognitive load.
Run 1
Code Structure: Logically organized into fields, constructor, accessors, and string representation. Nesting: Flat methods with no nested control flow. Clarity of intent: Descriptive class, field, and method names clearly communicate the event's purpose; explicit null checks clarify required inputs. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each assignment, validation, and return occupies its own line; constructor assignments naturally combine validation with initialization. Reading flow: Conventional Java ordering makes the class 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: The code is flat, with no nested control flow. Clarity of intent: Descriptive class and member names, explicit types, and null checks clearly communicate an event carrying partition and isolation-level information. Code length: The implementation is concise, without unnecessary logic or duplication. Action granularity: Each statement performs a single clear action; the string concatenation is straightforward. Reading flow: The class reads naturally from state definition through initialization to access and representation. Minor formatting issues, including the lack of separation between the package and imports and a long constructor signature, slightly reduce readability.
Run 3
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 an event for querying current lag; constructor null checks make requirements explicit. Code length: Concise, with minimal boilerplate and no unnecessary logic. Action granularity: Each statement performs a single clear action; the string concatenation is straightforward. Reading flow: Natural progression from initialization to access and representation. Minor formatting issues, including tightly grouped package/import declarations and a long constructor signature, slightly reduce readability.