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 is well-structured as a small, focused class with clear imports and a concise Javadoc. Nesting is minimal—only a single constructor and three overridden methods, each simple and flat. The intent of representing a long integer literal in an AST is immediately apparent from the class name, field names, and method purposes. Code length is appropriate: no redundant or boilerplate-heavy blocks. Action granularity is good, with one logical action per line, such as assigning the TypedValue or pushing the descriptor. The reading flow is natural, following a standard order: fields, constructor, then overridden methods in a logical sequence. Minor deductions are only for the lack of inline comments on the code generation method, which could clarify the bytecode operation, and for the slightly terse variable name "mv" though it is a common convention in this context.
Run 3
The code is highly readable, with a clear and logical structure. The class extends a fitting parent, fields are private and final, and constructor parameters are meaningful. Nesting is minimal; methods are flat and concise. Each method expresses a single purpose clearly, e.g., isCompilable returning true and generateCode performing two distinct actions on separate lines. Action granularity is appropriate—no line packs multiple unrelated operations. Reading flow is natural: package, imports, class-level Javadoc, field declaration, constructor, then overridden methods in a logical order. The code is concise without sacrificing clarity, and naming is explicit (e.g., exitTypeDescriptor). The only minor point preventing a perfect score is the lack of Javadoc on the constructor or methods, though the class-level comment and method names sufficiently convey intent.
Run 1
Code Structure: Clearly organized class with a field, constructor, and focused overridden methods. Nesting: Flat implementation with no nested control flow. Clarity of intent: Class documentation and descriptive method names make its purpose clear; the JVM descriptor "J" and abbreviation "mv" require some domain knowledge. Code length: Concise, with no unnecessary logic, though extra blank lines add minor visual space. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from initialization to value access, compilability, and bytecode generation.
Run 2
Code Structure: Clearly organized into a field, constructor, and small overridden methods. Nesting: Flat, with no conditional branches or nested blocks. Clarity of intent: The class documentation and method names clearly identify a long-literal AST node; the "J" type descriptor and abbreviated parameters require some JVM/domain knowledge. Code length: Concise, with no unnecessary implementation logic, though extra blank lines add minor visual spacing. Action granularity: Each statement performs one distinct action on its own line. Reading flow: Natural progression from initialization to value access, compilability, and code generation, supported by consistent formatting.
Run 3
Code Structure: The class is logically organized into a field, constructor, and focused overrides. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class documentation, descriptive names, and simple implementations clearly communicate its role as a long-literal AST node; the JVM descriptor "J" and abbreviation "cf" require some domain knowledge. Code length: The implementation is concise, with only minor excess whitespace. Action granularity: Each statement performs a single action on its own line. Reading flow: The progression from initialization to value access, compilation eligibility, and code generation is natural and easy to follow.