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 par, final IsolationLevel isolation, final long deadline) {
super(Type.CURRENT_LAG, deadline);
this.partition = Objects.requireNonNull(par);
this.isolationLevel = Objects.requireNonNull(isolation);
}
public TopicPartition par() {
return partition;
}
public IsolationLevel isolation() {
return isolationLevel;
}
@Override
public String to() {
return super.toStringBase() + ", partition=" + partition + ", isolationLevel=" + isolationLevel;
}
}
Run 1
The code is highly readable. It follows a clear logical structure with package declaration, imports, and a well-defined class. Nesting is minimal, with no conditional blocks or loops. Intent is clear: the class represents a current lag event with a partition, isolation level, and deadline. Code length is concise and appropriately scoped, with no unnecessary lines. Action granularity is one action per line, particularly in the constructor where null checks are assigned to fields. Reading flow is natural, with fields, constructor, accessors, and toString override in logical order. Minor deduction: method 'par()' could be named 'partition()' for clarity, and 'to()' is an unconventional toString override name, though its purpose is understandable.
Run 2
The code is highly readable due to its clear structure, minimal nesting, and concise methods. The class has a single responsibility, and fields are final with validation via requireNonNull. Method names like par() and isolation() are slightly abbreviated, but acceptable in this context. The toString override uses the base method cleanly. Overall, the code follows good practices with one action per line and natural reading flow.
Run 3
The code is highly readable. It follows a logical structure with a clear class hierarchy, simple fields, constructor, accessors, and an overridden method. It has minimal nesting, with only a single class and one method override. Intent is explicit: representing a current lag event with a partition and isolation level. The code is concise with no redundant lines; it uses Java best practices like `Objects.requireNonNull` and final fields. Each action (field assignment, return, method call) is on a separate line, aiding readability. Reading flow is natural, from package declaration and imports to class definition, fields, constructor, accessors, and the overridden `toString` method. Minor improvements could be better parameter names (`partition` instead of `par`) and a more descriptive method name than `to`, but overall readability is excellent.
Run 1
Code Structure: logically organized into fields, constructor, accessors, and an overridden method. Nesting: flat, with no complex control flow. Clarity of intent: the class name, field types, and null checks communicate its purpose, but abbreviated names such as par() and especially to() weaken clarity. Code length: concise, with little unnecessary code. Action granularity: each statement performs one clear action; the string concatenation remains easy to follow. Reading flow: natural top-to-bottom progression, though separating package and import declarations with a blank line and using descriptive, consistent method and parameter names would improve readability.
Run 2
Code Structure: Fields, constructor, accessors, and string representation are logically organized. Nesting: No nested control flow, making the class easy to scan. Clarity of intent: The class name and field types convey its purpose, but abbreviated names such as par() and the ambiguous to() obscure intent; to() with @Override also raises uncertainty about the superclass contract. Code length: Compact, with no unnecessary logic. Action granularity: Each statement performs a single clear action, including constructor validation. Reading flow: The ordering is natural, though inconsistent naming between fields, parameters, and accessors adds friction, and separating the package declaration from imports would improve presentation.
Run 3
Code Structure: Clearly organized into imports, fields, constructor, accessors, and an override. Nesting: Flat, with no complex control flow. Clarity of intent: The class name, field types, event type, and null checks communicate purpose well, but abbreviated names such as par() and the unusual to() method obscure intent; the latter's override contract is unclear without the superclass. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear action. Reading flow: Natural top-to-bottom progression, although abbreviated method names and the lack of spacing between the package and import groups slightly reduce readability.