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) {
mv.visitLdcInsn(this.value.getValue());
cf.pushDescriptor(this.exitTypeDescriptor);
}
}
Run 1
The code is highly readable. It has a clear, logical structure with a single class, well-named fields, and a straightforward constructor. Nesting is minimal; there are no deeply nested control structures. The intent of each method is explicit: retrieving the literal value, checking compilability, and generating bytecode. Code length is concise and appropriate for the functionality. Action granularity is sensible, with one logical action per line in the generateCode method. Reading flow is natural, with the class definition, field, constructor, and methods arranged in a conventional order. Minor deductions would only reflect the lack of explicit null or bounds checks, but for a literal AST node this is acceptable and idiomatic.
Run 2
The code is highly readable. It has clear structure with a single class, concise constructors, and simple overridden methods. Nesting is minimal, and each method performs a single action. The purpose of the class and each method is obvious from naming and annotations. Code length is appropriate for the functionality. The only minor drawback is the slight redundancy in setting `exitTypeDescriptor` in the constructor while using it later in `generateCode`, but this doesn't significantly affect readability.
Run 3
The code is highly readable. It has a clear, logical structure with a single class, a single field, a straightforward constructor, and three simple overridden methods. Nesting is minimal, with no conditional blocks or loops. The intent is explicit: represent a long literal in an expression language AST. Code length is concise, with each method performing a single, well-defined action. Action granularity is appropriate—each line performs one operation, such as setting a field, returning a value, or invoking a visitor method. Reading flow is natural, progressing from field declaration to constructor to getters and code generation. Naming conventions are clear and consistent with Spring's style. The only minor deduction is that the `getLiteralValue` method's name could be slightly more explicit, but it is conventional within this codebase. Overall, it is clean, maintainable, and exemplary for a simple AST node implementation.
Run 1
Code Structure: The class is logically organized into a field, constructor, and small overridden methods. Nesting: There are no nested conditionals or loops, making the code easy to scan. Clarity of intent: The class documentation and method names clearly identify its purpose as a long-integer literal AST node; the JVM descriptor "J" and abbreviated parameters mv and cf require some domain knowledge. Code length: The implementation is concise, with no unnecessary logic, though extra blank lines slightly dilute compactness. Action granularity: Each statement performs a single clear action. Reading flow: Initialization, value access, compilation support, and code generation appear in a natural sequence.
Run 2
Code Structure: The class is logically organized into a field, constructor, and focused overridden methods. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class documentation and method names clearly identify its purpose as a long literal AST node; the JVM descriptor "J" and abbreviated parameters mv and cf require some domain knowledge. Code length: The implementation is concise, with no unnecessary logic. Action granularity: Each statement performs one clear action on its own line. Reading flow: Initialization precedes value access and compilation methods, creating a natural progression. Minor excess blank lines do not materially impair readability.
Run 3
Code Structure: The class is logically organized, with a field, constructor, and focused overridden methods. Nesting: All methods are flat, with no conditional or loop nesting. Clarity of intent: The class documentation, descriptive method names, and straightforward implementations clearly convey its role as a long literal AST node; the descriptor "J" and abbreviation "cf" require some domain knowledge. Code length: The implementation is concise, with no unnecessary logic. Action granularity: Each statement performs one distinct action on its own line. Reading flow: The progression from initialization to value retrieval, compilability, and code generation is natural. Minor excess blank lines slightly reduce visual compactness.