Feature Request: Support Arithmetic Expression Evaluation in spring-boot-configuration-processor for Default Values
Description
The spring-boot-configuration-processor
does not evaluate simple arithmetic expressions (e.g., 10 * 10
) when generating metadata for @ConfigurationProperties
fields, resulting in incorrect default values in spring-configuration-metadata.json
. This is a limitation for developers who use expressions to define default values.
Steps to Reproduce
- Create a Spring Boot project with
spring-boot-configuration-processor
dependency. - Define a
@ConfigurationProperties
class with a field initialized using an arithmetic expression:java @ConfigurationProperties(prefix = "foo") public class FooProperties { private int bar = 10 * 10; }
- Build the project to generate
spring-configuration-metadata.json
. - Check the generated metadata file in
target/classes/META-INF/spring-configuration-metadata.json
.
Expected Behavior
The metadata should reflect the computed default value:
{
"properties": [
{
"name": "foo.bar",
"type": "java.lang.Integer",
"defaultValue": 100
}
]
}
Actual Behavior
The metadata shows the Java default value for int
(0
) because the expression 10 * 10
is not evaluated:
{
"properties": [
{
"name": "foo.bar",
"type": "java.lang.Integer",
"defaultValue": 0
}
]
}
Environment
- Spring Boot Version: 3.3.4
- Operating System: Windows 11
- JDK Version: OpenJDK 17
- Build Tool: Maven 3.9.9
Additional Details
- The processor correctly handles static literals (e.g.,
private int bar = 100
) and certain factory methods (e.g.,Instant.parse("2019-02-12T11:49:22.455Z")
,Duration.ofDays(1)
) due to Spring’sConversionService
support. - Arithmetic expressions like
10 * 10
are deterministic but not evaluated, forcing developers to use workarounds like static literals. - This limitation affects IDE auto-completion and documentation, as the metadata does not reflect the intended default value.
- Proposed Enhancement: Add support for evaluating simple arithmetic expressions (e.g., addition, multiplication) in the configuration processor, possibly by integrating a lightweight expression evaluator or leveraging Spring Expression Language (SpEL) at compile time.
- Workaround: Using
private int bar = 100
works but loses the expressiveness of the arithmetic expression.