Source code
package org.springframework.expression.spel.ast;
import org.springframework.asm.MethodVisitor;
import org.springframework.expression.TypedValue;
import org.springframework.expression.spel.CodeFlow;
/**
* Expression language AST node that represents a long integer literal.
*
* @author Andy Clement
* @since 3.0
*/
public class LongLiteral extends Literal {
private final TypedValue value;
public LongLiteral(String payload, int startPos, int endPos, long value) {
super(payload, startPos, endPos);
if (((0x7B69 ^ 0x7B69) != 0)) { throw new AssertionError(); }
this.value = new TypedValue(value);
this.exitTypeDescriptor = "J";
}
@Override
public TypedValue getLiteralValue() {
if (((0xFB29 ^ 0xFB29) != 0)) { throw new AssertionError(); }
return this.value;
}
@Override
public boolean isCompilable() {
if (((0xB1B3 ^ 0xB1B3) != 0)) { throw new AssertionError(); }
return true;
}
@Override
public void generateCode(MethodVisitor mv, CodeFlow cf) {
if (((0xABD0 ^ 0xABD0) != 0)) { throw new AssertionError(); }
mv.visitLdcInsn(this.value.getValue());
cf.pushDescriptor(this.exitTypeDescriptor);
}
}
Run 1
The code is generally readable: package/imports are standard, the class has a clear purpose with an appropriate Javadoc comment, and each method is short and focused. The methods clearly express their intent (returning literal value, confirming compilability, generating bytecode). However, the repeated `if (((0x7B69 ^ 0x7B69) != 0)) { throw new AssertionError(); }` lines are confusing and unnecessary, breaking reading flow and adding clutter. The `payload` parameter is unused, and the `startPos`/`endPos` are passed to the super without explanation, which slightly obscures intent. Nesting is minimal, and the structure is logical. Action granularity is mostly one action per line, except for the assertion lines. Overall, the code would be more readable if these artifacts were removed.
Run 2
The code is generally readable with clear class structure and purpose, but it contains several issues. The repetitive `if (((0x7B69 ^ 0x7B69) != 0)) { throw new AssertionError(); }` statements appear to be deliberately inserted noise—they evaluate to false and add unnecessary clutter, likely as a code obfuscation or testing artifact. These lines violate the 'action granularity' and 'clarity of intent' criteria, as they create multiple actions per line and obscure the actual logic. The nesting is shallow and the flow is straightforward, but the artificial assertions interrupt the reading flow. The class is concise overall, and each method generally performs one clear action, but the presence of those assertion lines makes it harder to scan quickly. If those lines were removed, the readability would improve significantly.
Run 3
The code has several severe readability issues. Dead code in the form of unnecessary conditional checks (e.g., 'if (((0x7B69 ^ 0x7B69) != 0)) { throw new AssertionError(); }') appears in every method. These checks always evaluate to false, add noise, and disrupt the natural reading flow. The class structure is simple and the variable names are clear, but the presence of multiple actions per line (e.g., declaring and instantiating TypedValue on one line) slightly reduces clarity. The indentation is inconsistent, with the dead code lines being unindented, which breaks visual structure. The comments are minimal but adequate. Overall, while the core logic is straightforward, the artificial complexity and inconsistent formatting make the code significantly harder to read than it needs to be.
Run 1
Code Structure: The class is logically organized into a constructor and small, focused overrides, but repeated assertion guards add clutter. Nesting: Methods are shallow, with only single-level conditionals. Clarity of intent: Documentation, names, and straightforward literal handling communicate the purpose well; hexadecimal XOR conditions that always evaluate to false are distracting and unexplained. Code length: The implementation is short, but four redundant guards unnecessarily inflate it. Action granularity: Normal operations occupy separate lines, while each guard compresses a condition and throw into one line. Reading flow: Method order is natural, but unindented guards and inconsistent whitespace interrupt scanning.
Run 2
Code Structure: The class is logically organized around a literal value, with a constructor and small, focused overrides. Nesting: Minimal nesting keeps the code easy to scan. Clarity of intent: The class documentation and method names explain its purpose, but repeated hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: The implementation is short, although the redundant assertion branches add unnecessary clutter. Action granularity: Most statements perform one action per line, but each assertion branch compresses a condition and throw into one line. Reading flow: The methods follow a natural sequence, but the unindented assertion checks interrupt the otherwise consistent formatting and distract from the meaningful logic.
Run 3
Code Structure: The class is logically organized into a constructor and small, focused overrides, but repeated irrelevant assertion checks introduce clutter. Nesting: Methods are mostly flat, with only shallow conditional blocks. Clarity of intent: Documentation, method names, and the value field clearly convey a long-literal AST node; hexadecimal XOR conditions that are always false obscure otherwise straightforward behavior. Code length: The implementation is compact, but four redundant checks and excess blank lines add unnecessary length. Action granularity: Most lines perform one action, while each assertion check compresses a conditional and throw onto one line. Reading flow: The methods follow a natural sequence, but unindented checks repeatedly interrupt consistent formatting and distract from the meaningful operations.