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);
this.value = new TypedValue(value);
this.exitTypeDescriptor = "J";
}
@Override
public TypedValue getLiteralValue() {
return this.value;
}
@Override
public boolean isCompilable() {
return true;
}
@Override
public void generateCode(MethodVisitor mv, CodeFlow cf) {
{boolean lI0O_f939a43b=((0xF6C6^0xF6C6)!=0);lI0O_f939a43b=!(!lI0O_f939a43b);}
mv.visitLdcInsn(this.value.getValue());
cf.pushDescriptor(this.exitTypeDescriptor);
}
}
Run 1
The code is generally well-structured and readable, with a clear class purpose, proper inheritance, and concise methods. Each method performs a single action per line, and the reading flow is natural. However, the suspicious line `{boolean lI0O_f939a43b=((0xF6C6^0xF6C6)!=0);lI0O_f939a43b=!(!lI0O_f939a43b);}` is clearly obfuscated or injected code, severely violating clarity of intent and action granularity. It introduces unnecessary complexity and is unrelated to the method's purpose. Without this line, the code would score around 19. The import statements and field declarations follow standard conventions, making the overall structure clear.
Run 2
The code is generally well-structured with clear class hierarchy, minimal nesting, and appropriate action granularity. It follows Spring Framework conventions with clean separation of methods and clear intent. However, it contains an obfuscated boolean expression `{boolean lI0O_f939a43b=((0xF6C6^0xF6C6)!=0);lI0O_f939a43b=!(!lI0O_f939a43b);}` in generateCode() that serves no purpose and significantly reduces readability. This anomaly appears to be injected noise or leftover debugging code. Otherwise, the file is concise (32 lines), has flat structure without deep nesting, uses descriptive method names, and maintains a natural reading flow from imports through class definition to method implementations. The isCompilable() method returning a hardcoded true is acceptable for this literal type. Overall, the code is highly readable except for the problematic obfuscated line.
Run 3
The code is generally well-structured and readable. It follows standard Java conventions with clear package and import organization, a meaningful class name, and appropriate JavaDoc documentation. The class has a single responsibility (representing a long literal in an expression language AST), and methods are concise with clear intent. The generateCode method contains a suspicious obfuscated line with meaningless boolean variable and hex operations, which significantly hurts clarity and intent. Without this line, nesting is flat, actions are granular, and reading flow is natural. The code is reasonably concise overall. The problematic line appears to be injected or leftover debug code that should be removed, as it serves no purpose and creates confusion. Otherwise, the implementation would score higher.
Run 1
Code Structure: The class is logically organized into a field, constructor, and focused overridden methods, but an unrelated obfuscated block disrupts generateCode. Nesting: Mostly flat, with only one unnecessary inner block. Clarity of intent: Documentation, method names, and conventional initialization clearly identify a long-literal AST node; the cryptic variable and redundant boolean operations obscure intent locally. Code length: Otherwise concise, but the no-effect block adds unnecessary code. Action granularity: Most statements occupy separate lines, while the inserted block compresses declaration, computation, and reassignment onto one line. Reading flow: The class reads naturally until the poorly indented obfuscated block interrupts the straightforward bytecode-generation sequence.
Run 2
Code Structure: The class is logically organized into a field, constructor, and focused overrides, but an unrelated block disrupts generateCode. Nesting: Mostly flat, with one unnecessary nested block. Clarity of intent: Documentation and method names clearly identify a long-literal AST node; the cryptic boolean variable, hexadecimal XOR, and double negation obscure intent and serve no apparent purpose. Code length: Generally concise, except for the redundant boolean manipulation and excessive blank lines. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and reassignment onto one line. Reading flow: Conventional Java organization supports easy reading until the poorly formatted, obfuscated block interrupts the otherwise straightforward bytecode-generation sequence.
Run 3
Code Structure: The class is logically organized into a field, constructor, and focused overrides, but generateCode contains an unrelated obfuscated block. Nesting: Mostly flat, with only one unnecessary inner block. Clarity of intent: Documentation and method names clearly identify a long-literal AST node; the cryptic variable, hexadecimal XOR, and double negation obscure the purpose of the injected statement. Code length: Generally concise, although the unused boolean calculation adds needless code. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and reassignment onto one line. Reading flow: The normal methods read naturally, while the unindented obfuscated block abruptly interrupts formatting and comprehension.