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 previousAuthenticator, NetworkReceive networkReceive, long nowNanos) { this.previousAuthenticator = Objects.requireNonNull(previousAuthenticator); this.networkReceive = networkReceive; this.reauthenticationBeginNanos = nowNanos;
}
/**
* 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 networkReceive() {
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 previousAuthenticator() { 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 reauthenticationBeginNanos() { return reauthenticationBeginNanos;
}
}
Run 1
The code has clear intent as a simple data holder class, but suffers from severe formatting issues that drastically reduce readability. The package and import statements are jammed onto a single line, multiple fields are declared on one line, and method bodies are placed on the same line as their signatures. This violates typical Java conventions and makes the code appear tangled. The constructor has three assignments on one line, breaking the 'one action per line' principle. While the Javadoc comments are thorough and helpful, the inconsistent spacing and compressed layout disrupt natural reading flow. The class structure itself is logically sound, but the physical presentation negates most of the structural clarity. With proper formatting, this would be a very readable class; as presented, it requires significant effort to parse visually.
Run 2
The code has major readability issues. The package and import statements are on the same line, and field declarations, methods, and Javadoc are crammed together without proper line breaks. The constructor body is one line with multiple assignments, violating the one-action-per-line principle. Method bodies lack consistent formatting—some are on one line, others are split inconsistently. The Javadoc is verbose and poorly formatted, making it hard to scan. Although the code is logically simple and not deeply nested, the physical layout severely disrupts reading flow and clarity of intent. The class is short and could be readable with standard formatting, but as written it is unnecessarily difficult to parse.
Run 3
The code has serious formatting issues that drastically reduce readability. The package and import statements are on the same line, making the top of the file difficult to scan. Multiple method signatures are compressed onto single lines, violating typical Java conventions and making the code harder to parse. Some closing braces are placed on the same line as subsequent method declarations, breaking logical separation. The Javadoc comments are well-written and detailed, which is a positive, but their formatting is inconsistent with the actual code layout. The class has a clear purpose and simple getter methods, but the physical presentation obscures this clarity. Nesting is minimal, and action granularity is acceptable, but the reading flow is severely compromised by the formatting inconsistencies.
Run 1
Code Structure: Fields, constructor, and accessors are logically organized, but compressed declarations weaken visual separation. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Descriptive names, final fields, null validation, and detailed documentation clearly convey the class's purpose and contracts. Code length: Implementation is concise, although repeated documentation adds unnecessary length. Action granularity: The constructor places three assignments on one line, and package/import declarations and some method bodies are also compressed. Reading flow: The overall sequence is natural, but inconsistent formatting and a documentation comment beginning immediately after a method interrupt scanning. Consistent line breaks and less repetitive documentation would improve readability.
Run 2
Code Structure: The class is logically organized into immutable fields, a constructor, and accessors, but compressed declarations obscure boundaries. Nesting: Minimal nesting and no branching make the code easy to follow. Clarity of intent: Descriptive names and detailed Javadoc clearly explain re-authentication context, nullability, and timing semantics. Code length: The implementation is concise, though documentation repeats substantial information. Action granularity: Multiple constructor assignments share one line, and package/import declarations and some method boundaries are compressed together, reducing scanability. Reading flow: The overall sequence is natural, but inconsistent formatting and comments starting immediately after method closures interrupt the flow.
Run 3
Code Structure: A logically organized context class with immutable fields, a constructor, and accessors, though compressed formatting obscures boundaries. Nesting: Minimal nesting and no complex control flow make it easy to follow. Clarity of intent: Descriptive names and detailed documentation clearly explain re-authentication state, nullability, and timing semantics. Code length: Implementation is concise, but repeated documentation adds unnecessary length. Action granularity: Multiple constructor assignments share one line, and package/import declarations and some method boundaries are crowded together. Reading flow: The fields-to-constructor-to-accessors sequence is natural, but inconsistent line breaks and comments attached to method endings interrupt scanning. Consistent formatting and less repetitive documentation would improve readability substantially.