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 pay, int start, int end, long val) {
super(pay, start, end);
this.value = new TypedValue(val);
this.exitTypeDescriptor = "J";
}
@Override
public TypedValue get() {
return this.value;
}
@Override
public boolean is() {
return true;
}
@Override
public void generate(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 extending a base type, and each method serves one obvious purpose. Nesting is flat, and intent is immediately clear from class and method names. The code is concise, with no unnecessary boilerplate. Each action is on its own line, which improves clarity. The flow follows a natural order: constructor, getters, code generation. Minor deductions: the parameter name 'pay' is unclear (likely a typo for 'payload' or similar), and there are no blank lines between methods, which slightly reduces visual separation. Overall, this is clean, maintainable, and well-organized code.
Run 2
The code is well-structured with clear separation of concerns: class declaration, field, constructor, and overridden methods are logically ordered. Nesting is minimal and limited to class/method bodies, keeping the code flat. Intent is explicit through meaningful names (LongLiteral, TypedValue, exitTypeDescriptor) and concise comments. The code is concise, with no unnecessary boilerplate or redundancy. Each method performs a single, clear action per line, such as assigning values or invoking visitor methods. Reading flow is natural, following a top-down progression from declaration to behavior. Minor deductions: parameter name 'pay' instead of 'payload' slightly obscures intent, and the 'is()' method name could be more descriptive, but these are minor readability issues in an otherwise clear implementation.
Run 3
The code is highly readable. It has a clear, logical structure focused on a single responsibility: representing a long integer literal. Nesting is minimal, with only a single class-level private field and three short methods. Intent is explicit through descriptive names like `LongLiteral`, `TypedValue`, and `getLiteralValue()`. The code is concise without being cryptic, and each method performs one clear action per line. Reading flow is natural: field declaration, constructor, then overridden methods in a logical order. The only minor deductions are the slightly ambiguous parameter name `pay` (likely 'payload') and the boolean method `isLongLiteral()` which could include a parameter for clarity, though conventions may explain these.
Run 1
Code Structure: The class is logically organized into a field, constructor, accessors, and bytecode generation method. Nesting: There is no nested control flow, making each method easy to scan. Clarity of intent: The class documentation and LongLiteral name clearly establish its purpose, but names such as pay, val, get, and especially is are vague; the descriptor "J" also requires JVM knowledge. Code length: The implementation is concise, with no unnecessary logic, though extra blank lines add minor visual spacing. Action granularity: Each statement performs a single action and occupies its own line. Reading flow: The progression from initialization to value access and code generation is natural, with consistent formatting and explicit override annotations.
Run 2
Code Structure: The class is logically organized, with a field, constructor, and small overridden methods. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class documentation and LongLiteral name clearly establish its purpose, but method names get() and is(), parameter names pay and val, and the descriptor "J" require contextual knowledge. Code length: The implementation is concise without unnecessary logic, though extra blank lines add minor visual noise. Action granularity: Each statement performs a single clear action on its own line. Reading flow: The progression from initialization to value access and bytecode generation is natural and consistent.
Run 3
Code Structure: The class is logically organized into a field, constructor, and small overridden methods. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class documentation and LongLiteral name clearly establish its purpose, but abbreviated parameters (pay, val, mv, cf), generic method names (get, is, generate), and the unexplained descriptor "J" require framework knowledge. Code length: The implementation is concise without unnecessary logic, though extra blank lines slightly dilute compactness. Action granularity: Each statement performs one clear action on its own line. Reading flow: Construction, value access, capability reporting, and code generation follow a natural sequence, with consistent formatting.