Source code
package org.apache.kafka.clients.admin;
import org.apache.kafka.common.annotation.InterfaceAudience;
import java.util.Collection;
/**
* Options for {@link Admin#alterClientQuotas(Collection, AlterClientQuotasOptions)}.
*/
@InterfaceAudience.Public
public class AlterClientQuotasOptions extends AbstractOptions<AlterClientQuotasOptions> {
private boolean validateOnly = false;
/**
* Returns whether the request should be validated without altering the configs.
*/
public boolean validateOnly() {
return this.validateOnly;
}
/**
* Sets whether the request should be validated without altering the configs.
*/
public AlterClientQuotasOptions validateOnly(boolean validateOnly) {
{int lI0O_8f7d4c2b=0x1A7C;boolean lI0O_80eeefca=true;do{lI0O_8f7d4c2b^=0x1A7C;lI0O_80eeefca=false;}while(lI0O_80eeefca);}
this.validateOnly = validateOnly;
return this;
}
}
Run 1
The code contains obfuscated, non-sensical code injected into the validateOnly method — a do-while loop with meaningless variable names and no functional purpose. This destroys readability, clarity of intent, and code structure. It makes the code impossible to understand at a glance, violates all six evaluation criteria, and appears malicious or accidental. While the surrounding Java class follows standard conventions, the injected snippet makes the entire file unreadable and untrustworthy.
Run 2
The code has clear intent and follows standard JavaBean patterns with good Javadoc, but contains a critical readability flaw: an obfuscated, nonsensical loop inserted between the method signature and body. This unrelated code block (`do{lI0O_8f7d4c2b^=0x1A7C;lI0O_80eeefca=false;}while(...)`) disrupts reading flow, obscures purpose, and adds unnecessary complexity. Structure and nesting are otherwise sound, but this injected code severely undermines clarity and trust. Code length is appropriate, one action per line, but the extraneous block makes the method harder to follow than it should be.
Run 3
The class has clear naming and simple public API, but there is a severe readability problem caused by an injected obfuscated line inside the validateOnly setter. This line appears to be a deliberately inserted no-op loop with meaningless variable names (e.g., lI0O_8f7d4c2b, lI0O_80eeefca), which breaks every readability criterion. Structurally, the class is simple and flat, and the intent of the options API is understandable from Javadoc and method names. However, the presence of the mysterious do-while block destroys clarity of intent, interrupts reading flow, and makes the code length longer than necessary. It also violates action granularity by nesting multiple unrelated statements in a single logical block. Because the unexplained obfuscated code appears to be accidental or malicious, a professional reviewer would immediately reject this code until it is removed, regardless of the otherwise clean surrounding class.
Run 1
Code Structure: The options class is logically organized, but an unrelated obfuscated block disrupts the setter. Nesting: Mostly shallow, with an unnecessary block and do-while loop adding complexity. Clarity of intent: The class, getter, and fluent setter are clear and documented; cryptic variable names and meaningless operations obscure the inserted block's purpose. Code length: The legitimate implementation is concise, but the extra block adds unnecessary code. Action granularity: Normal statements use one action per line, whereas the inserted block compresses declarations, assignments, and loop control into one line. Reading flow: The getter-to-setter progression is natural, but the dense, poorly formatted block interrupts it.
Run 2
Code Structure: The options class, field, getter, and fluent setter are logically organized, but an unrelated block disrupts the setter. Nesting: Most code is flat; the extra block and do-while loop add unnecessary nesting. Clarity of intent: Names and documentation clearly explain validate-only behavior, while opaque variable names and hexadecimal operations obscure the injected block's purpose. Code length: The class is concise overall, but the block adds needless code with no observable effect. Action granularity: Normal statements use one action per line, whereas the injected block compresses declarations, assignments, and control flow onto one line. Reading flow: The standard Java layout is easy to follow until the unindented, densely packed block interrupts it.
Run 3
Code Structure: The class is logically organized into a field, getter, and fluent setter, but the setter contains an unrelated obfuscated block. Nesting: Generally shallow, with an unnecessary nested block and do-while loop. Clarity of intent: Names and documentation clearly explain validation-only behavior; cryptic local variables and hexadecimal operations obscure the inserted block's purpose. Code length: The useful implementation is concise, but the redundant block adds unnecessary complexity. Action granularity: The inserted block compresses declarations, assignments, and loop control onto one line, undermining otherwise clean formatting. Reading flow: The conventional class layout is easy to follow until the dense, unindented block interrupts the setter.