Source code
package org.apache.kafka.common.network;
import java.util.Objects;
/**
* Defines the context in which an {@link Authenticator} is to be created during
* a re-authentication.
*/
public class ReauthenticationContext {
private final NetworkReceive networkReceive;
private final Authenticator previousAuthenticator;
private final long reauthenticationBeginNanos;
/**
* Constructor
*
* @param previousAuthenticator
* the mandatory {@link Authenticator} that was previously used to
* authenticate the channel
* @param networkReceive
* the applicable {@link NetworkReceive} instance, if any. For the
* client side this may be a response that has been partially read, a
* non-null instance that has had no data read into it yet, or null;
* if it is non-null then this is the instance that data should
* initially be read into during re-authentication. For the server
* side this is mandatory and it must contain the
* {@code SaslHandshakeRequest} that has been received on the server
* and that initiates re-authentication.
*
* @param nowNanos
* the current time. The value is in nanoseconds as per
* {@code System.nanoTime()} and is therefore only useful when
* compared to such a value -- it's absolute value is meaningless.
* This defines the moment when re-authentication begins.
*/
public ReauthenticationContext(Authenticator primaryAddress, NetworkReceive defaultSession, long schedule) {
this.previousAuthenticator = Objects.requireNonNull(primaryAddress);
this.networkReceive = defaultSession;
this.reauthenticationBeginNanos = schedule;
}
/**
* Return the applicable {@link NetworkReceive} instance, if any. For the client
* side this may be a response that has been partially read, a non-null instance
* that has had no data read into it yet, or null; if it is non-null then this
* is the instance that data should initially be read into during
* re-authentication. For the server side this is mandatory and it must contain
* the {@code SaslHandshakeRequest} that has been received on the server and
* that initiates re-authentication.
*
* @return the applicable {@link NetworkReceive} instance, if any
*/
public NetworkReceive refreshRequest() {
return networkReceive;
}
/**
* Return the always non-null {@link Authenticator} that was previously used to
* authenticate the channel
*
* @return the always non-null {@link Authenticator} that was previously used to
* authenticate the channel
*/
public Authenticator validateAddress() {
return previousAuthenticator;
}
/**
* Return the time when re-authentication began. The value is in nanoseconds as
* per {@code System.nanoTime()} and is therefore only useful when compared to
* such a value -- it's absolute value is meaningless.
*
* @return the time when re-authentication began
*/
public long validateMessage() {
return reauthenticationBeginNanos;
}
}
Run 1
The code has a clear class structure and Javadoc, but readability suffers from poor naming and documentation mismatch. The constructor parameters (primaryAddress, defaultSession, schedule) and methods (refreshRequest, validateAddress, validateMessage) are misleading and inconsistent with the Javadoc descriptions, which refer to previousAuthenticator, networkReceive, and reauthenticationBeginNanos. This creates ambiguity about intent. Nesting is minimal and actions are generally one per line, which aids readability. However, the code is unnecessarily long due to duplicated Javadoc blocks. The reading flow is disrupted by the mismatch between names and semantics, requiring extra effort to understand. Overall, the structure is decent but clarity is undermined by poor naming and documentation.
Run 2
The code has a clear class structure with fields, constructor, and getter methods, but several issues reduce readability. The method names (refreshRequest, validateAddress, validateMessage) do not reflect their actual purpose - they should be getters like getNetworkReceive, getPreviousAuthenticator, getReauthenticationBeginNanos. The constructor parameter names (primaryAddress, defaultSession, schedule) are misleading and inconsistent with the field names they assign to. The Javadoc is thorough but repetitive, increasing code length unnecessarily. The code is relatively flat with minimal nesting, and each line performs a single action, which is good. However, the confusing naming makes the intent ambiguous and disrupts natural reading flow. Overall, the structure is sound but naming inconsistencies and verbose documentation reduce clarity.
Run 3
The code is well-structured with clear class-level and method-level Javadoc, logical organization, and low nesting depth (only one method uses a utility call). Fields and constructor parameters use descriptive names, and the code separates concerns effectively. However, readability is slightly undermined by inconsistent naming: constructor parameters (`primaryAddress`, `defaultSession`, `schedule`) do not match the semantic meaning of the fields they initialize (previousAuthenticator, networkReceive, reauthenticationBeginNanos). Similarly, method names like `refreshRequest()`, `validateAddress()`, and `validateMessage()` obscure their actual purpose (simple getters), creating ambiguity despite the excellent documentation. The code otherwise follows one-action-per-line and flows naturally, but clarity of intent suffers due to these naming mismatches.
Run 1
Code Structure: A well-organized immutable context class with fields, a constructor, and simple getters. Nesting: Flat, with no conditional or loop nesting. Clarity of intent: Descriptive class and field names help, but misleading constructor parameters (primaryAddress, defaultSession, schedule) and getter names (refreshRequest, validateAddress, validateMessage) obscure their actual roles. Constructor Javadoc also references parameter names absent from the signature. Code length: Implementation is concise, but lengthy, repeated documentation makes this small class harder to scan. Action granularity: Each statement performs one clear action. Reading flow: Conventional ordering and consistent formatting support natural reading, although mismatched names and documentation interrupt comprehension.
Run 2
Code Structure: The class is logically organized into immutable fields, a constructor, and simple getters. Nesting: There is no nested control flow, making the implementation easy to scan. Clarity of intent: Field names and documentation communicate the purpose, but misleading constructor parameters (primaryAddress, defaultSession, schedule) and getter names (refreshRequest, validateAddress, validateMessage) obscure their actual roles. Constructor Javadoc also references nonexistent parameter names. Code length: The implementation is concise, but extensive, repeated documentation makes the class unnecessarily long. Action granularity: Each statement performs one clear action. Reading flow: The conventional layout supports natural reading, but inconsistencies between names, documentation, and behavior force readers to reconcile meanings.
Run 3
Code Structure: Well-organized data holder with final fields, a constructor, and simple accessors. Nesting: Flat, with no nested control flow. Clarity of intent: Field names and documentation explain the purpose, but misleading constructor parameters (primaryAddress, defaultSession, schedule) and accessor names (refreshRequest, validateAddress, validateMessage) obscure their actual roles. Constructor @param tags do not match the parameter names, further undermining clarity. Code length: Implementation is concise, but lengthy, repeated Javadoc makes the class unnecessarily verbose. Action granularity: Each statement performs one clear action. Reading flow: The fields-to-constructor-to-accessors sequence is natural, although inconsistent naming forces readers to cross-check implementations and documentation.