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 a, NetworkReceive b, long c) {
this.previousAuthenticator = Objects.requireNonNull(a);
this.networkReceive = b;
this.reauthenticationBeginNanos = c;
}
/**
* 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 a() {
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 b() {
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 c() {
return reauthenticationBeginNanos;
}
}
Run 1
The code has clear documentation and a straightforward structure, but readability is severely undermined by poor naming. Constructor parameters 'a', 'b', 'c' and methods 'a()', 'b()', 'c()' are cryptic and fail to convey intent. The Javadoc is thorough but disconnected from the actual API names. The class is flat and logically organized, with one action per line, concise getters, and natural field/method ordering. However, the inability to infer purpose from names without reading external documentation makes the code ambiguous and hard to maintain.
Run 2
The code has decent structure and flat nesting, but readability is severely undermined by unclear naming. Parameters and methods use meaningless names like 'a', 'b', 'c', and 'ReauthenticationContext(Authenticator a, NetworkReceive b, long c)', obscuring intent despite verbose Javadoc. The constructor parameter order also conflicts with the documented order, adding confusion. While each line performs one action and the class is concise, the disconnect between documentation and actual code identifier names significantly harms clarity and reading flow.
Run 3
The code structure is logical, with a clear class and constructor, but the use of cryptic parameter and method names (a, b, c) severely undermines clarity of intent. There is minimal nesting and the reading flow is natural, but the public API becomes ambiguous, forcing readers to rely on documentation. Code length is concise but at the cost of self-documenting code. Action granularity is good - one action per line in the constructor and methods. The Javadoc is thorough, but it offsets rather than fixes the poor naming. Overall, the code is readable in structure but fails on clear, self-explanatory identifiers, which is crucial for maintainability and collaborative development.
Run 1
Code Structure: A logically organized context class with immutable fields, a constructor, and simple accessors. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive field names and documentation explain the purpose, but constructor parameters a/b/c and accessor names a()/b()/c() obscure meaning. The constructor's @param tags do not match its actual parameter names, further weakening clarity. Code length: Implementation is concise, but lengthy, repetitive documentation dominates the class. Action granularity: Each statement performs a single assignment, validation, or return. Reading flow: The fields-to-constructor-to-accessors sequence is natural, though opaque public names force readers to inspect method bodies or comments.
Run 2
Code Structure: Logically organized as a small context class with immutable fields, a constructor, and accessors. Nesting: Completely flat, with no complex control flow. Clarity of intent: Descriptive fields and documentation explain the purpose, but single-letter constructor parameters and accessor names obscure usage. Constructor @param names also fail to match the actual parameters. Code length: Implementation is concise, but lengthy, repetitive documentation makes the class unnecessarily verbose. Action granularity: Each statement performs one clear action. Reading flow: Conventional ordering supports easy navigation, though opaque method names and documentation duplication interrupt an otherwise natural flow.
Run 3
Code Structure: Logically organized as a small immutable context class with fields, a constructor, and accessors. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive class and field names help, but single-letter constructor parameters and accessor names obscure meaning. Constructor Javadoc also references parameter names that do not match the signature. Code length: Implementation is concise, but lengthy, repetitive documentation makes the class unnecessarily verbose. Action granularity: Each statement performs one clear action. Reading flow: Conventional ordering supports easy reading, although generic method names force readers to inspect bodies or documentation to understand their purpose.