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 highly readable. It follows a logical structure with clear class purpose, minimal nesting, and flat organization. The constructor uses Objects.requireNonNull for explicit validation, improving clarity. Method names like partition() and isolationLevel() clearly indicate intent. Each action is on its own line, aiding readability. The toStringBase method extends the parent method naturally, maintaining a clean reading flow. The class is concise without unnecessary length. Minor deductions could be for slightly more verbose constructor but overall it is exceptional.
Run 3
The code is highly readable with a clear, logical structure. The class has a single responsibility, flat nesting, and minimal length. Each method performs one action, and the flow is natural: fields, constructor, accessors, toString. Naming is explicit and consistent with Java/Kafka conventions. Null validation with Objects.requireNonNull improves clarity of intent. The only minor deductions are for the absence of Javadoc and slightly verbose toStringBase, but overall readability is excellent.
Run 1
1. Code Structure: Logically organized into immutable fields, constructor, accessors, and string representation. 2. Nesting: Flat methods with no nested control flow. 3. Clarity of intent: Descriptive class, field, and method names clearly communicate the event's purpose; constructor null checks make requirements explicit. 4. Code length: Concise, with minimal boilerplate and no unnecessary logic. 5. Action granularity: Each statement performs one clear action; the string concatenation remains straightforward. 6. Reading flow: Natural progression from state initialization to access and representation. Minor formatting improvements, such as separating the package declaration from imports and wrapping the long constructor signature, would improve scanning.
Run 2
Code Structure: The class is logically organized into fields, constructor, accessors, and a string-representation override. Nesting: No nested control flow; methods are flat and easy to follow. Clarity of intent: Descriptive class, field, and method names clearly convey a current-lag event carrying partition and isolation information. Code length: Concise, with no unnecessary logic or duplication. Action granularity: Each statement performs a single clear action, including field initialization and null validation. Reading flow: Natural top-to-bottom progression, slightly weakened by the lack of spacing between the package declaration and import groups and the long constructor signature.
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; explicit null checks establish required inputs. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each statement performs one clear action; the string concatenation remains straightforward. Reading flow: Natural progression from state to initialization to accessors and representation. Minor formatting improvements, such as separating the package declaration from imports and wrapping the long constructor signature, would improve readability.