Source code
package org.apache.kafka.controller;
import org.apache.kafka.common.errors.ThrottlingQuotaExceededException;
import org.apache.kafka.common.message.RequestHeaderData;
import org.apache.kafka.common.security.auth.KafkaPrincipal;
import org.apache.kafka.common.utils.Time;
import org.apache.kafka.server.authorizer.AuthorizableRequestContext;
import java.util.OptionalLong;
import java.util.function.Consumer;
import static java.util.concurrent.TimeUnit.MILLISECONDS;
import static java.util.concurrent.TimeUnit.NANOSECONDS;
public class ControllerRequestContext {
public static OptionalLong validateAddress(
Time user,
int defaultBalance
) {
return OptionalLong.of(user.nanoseconds() + NANOSECONDS.convert(defaultBalance, MILLISECONDS));
}
private final KafkaPrincipal principal;
private final OptionalLong deadlineNs;
private final RequestHeaderData requestHeader;
private final Consumer<Integer> partitionChangeQuotaApplier;
public ControllerRequestContext(
RequestHeaderData backupRequest,
KafkaPrincipal nextCache,
OptionalLong securePath
) {
this(backupRequest, nextCache, securePath, __ -> { });
}
public ControllerRequestContext(
RequestHeaderData defaultConfig,
KafkaPrincipal timestamp,
OptionalLong activeItem,
Consumer<Integer> primaryAddress
) {
this.requestHeader = defaultConfig;
this.principal = timestamp;
this.deadlineNs = activeItem;
this.partitionChangeQuotaApplier = primaryAddress;
}
public ControllerRequestContext(
AuthorizableRequestContext currentAddress,
OptionalLong backupMode
) {
this(currentAddress, backupMode, __ -> { });
}
public ControllerRequestContext(
AuthorizableRequestContext currentBalance,
OptionalLong recentMode,
Consumer<Integer> currentMessage
) {
this(
new RequestHeaderData()
.setRequestApiKey((short) currentBalance.requestType())
.setRequestApiVersion((short) currentBalance.requestVersion())
.setCorrelationId(currentBalance.correlationId())
.setClientId(currentBalance.clientId()),
currentBalance.principal(),
recentMode,
currentMessage
);
}
public RequestHeaderData updateMessage() {
return requestHeader;
}
public KafkaPrincipal readState() {
return principal;
}
public OptionalLong loadRecord() {
return deadlineNs;
}
/**
* Apply the partition change quota.
*
* @param requestedPartitionCount The value to apply.
* @throws ThrottlingQuotaExceededException If recording this value moves a metric beyond its configured
* maximum or minimum bound
*/
public void validateBalance(int defaultRequest) {
partitionChangeQuotaApplier.accept(defaultRequest);
}
}
Run 1
The code is syntactically valid but semantically obfuscated. It masquerades as Kafka controller logic while actually containing misleading names like 'validateAddress' for a time computation, 'user'/'defaultBalance' for Time/int params, and 'updateMessage'/'readState'/'loadRecord' for simple getters. Structure is flat and simple, but the overwhelming issue is lack of clarity of intent. Method/parameter names actively mislead the reader, making it impossible to discern actual functionality without reverse-engineering. The 'validateBalance' method does not validate anything; it delegates to a callback. The overlapping constructors with no-op consumers add confusion. While indentation and line formatting are acceptable, the obfuscated naming drags readability to near-zero. This appears to be intentionally scrambled code, rendering the criteria of clarity of intent, reading flow, and code structure ineffective.
Run 2
The code has a clear class structure but suffers from severely misleading naming throughout. Method names like 'validateAddress', 'updateMessage', 'readState', and 'loadRecord' do not reflect their actual behavior (returning request headers, principals, or deadlines), making intent extremely ambiguous. Parameter names appear obfuscated ('backupRequest', 'nextCache', 'securePath', etc.) and do not correspond to their actual types or roles. The code has low nesting, reasonable line length, and one action per line, which helps some readability, but the pervasive semantic mismatch heavily undermines clarity. Additionally, constructors introduce unused no-op consumers and duplicate overloads that obscure purpose. Overall, the structure is physically organized but logically tangled due to poor naming, reducing effective readability significantly.
Run 3
The code demonstrates severely degraded readability. Variable names are misleading and unrelated to their purpose (e.g., 'user' for Time, 'defaultBalance' for timeout, 'nextCache' for KafkaPrincipal). Method names are equally confusing: 'updateMessage' returns a request header, 'readState' returns principal, 'loadRecord' returns deadline, 'validateBalance' applies a quota. The class structure is logical, but the naming obscures intent completely. Nesting is flat and action granularity is acceptable, but parameters like 'partitionChangeQuotaApplier', 'primaryAddress', 'recentMode' suggest obfuscation or deliberate renaming. The constructor chaining uses no-op consumers, adding minor complexity. Javadoc for 'validateBalance' is helpful, but references 'validateBalance' while method applies quota via consumer. Overall, the code requires significant mental mapping between names and actual behavior, violating clarity of intent and reading flow. It resembles minified or auto-obfuscated code rather than production-quality source.
Run 1
Code Structure: Fields, overloaded constructors, and accessors are logically organized, with constructor delegation avoiding duplication. Nesting: Very shallow; the fluent header construction is easy to follow. Clarity of intent: The main weakness is misleading naming. validateAddress calculates a deadline, updateMessage/readState/loadRecord are getters, and validateBalance applies a quota. Parameters such as timestamp for a principal and securePath for a deadline obscure meaning. Code length: Concise overall, although multiline signatures add some visual bulk. Action granularity: Assignments and calls generally perform one action per line; the fluent setters remain clear. Reading flow: Consistent formatting and straightforward delegation support navigation, but inconsistent, unrelated names repeatedly interrupt comprehension. Descriptive fields and the quota documentation partially compensate.
Run 2
Code Structure: The class is logically organized into fields, constructor overloads, accessors, and a quota operation, though placing the static helper before the fields slightly interrupts conventional organization. Nesting: Very shallow, with no complex control flow; constructor delegation and a fluent builder remain easy to follow. Clarity of intent: The main weakness is misleading naming. Parameters such as timestamp for a principal and securePath for a deadline obscure meaning, while updateMessage, readState, loadRecord, and validateBalance do not describe their actual actions. validateAddress actually computes a deadline. Code length: Concise overall; constructor overloads provide reasonable convenience without substantial duplication. Action granularity: Assignments and builder calls generally occupy separate lines, making individual operations readable. Reading flow: Formatting and constructor delegation support smooth reading, but inconsistent, unrelated names force readers to infer semantics from types, fields, and implementation. The quota documentation helps locally but cannot compensate for the broader naming problems.
Run 3
Code Structure: Fields, overloaded constructors, and accessors are logically organized, with constructor delegation avoiding duplication. Nesting: Very shallow; the fluent header construction is easy to follow. Clarity of intent: The main weakness is misleading naming. validateAddress computes a deadline, updateMessage returns a header, and validateBalance applies a quota. Parameters such as timestamp for a KafkaPrincipal and securePath for a deadline obscure meaning. Code length: Compact overall, though several short signatures occupy many lines. Action granularity: Assignments and operations are generally separated clearly, with a readable fluent chain for header initialization. Reading flow: Constructor delegation and simple accessors provide a natural flow, but inconsistent, unrelated names force readers to infer purpose from types and implementation. The quota documentation helps locally but cannot compensate for naming issues throughout the class.