Prior to this commit, if a Spring Expression Language (SpEL) expression
contained property, field, or method references using the null-safe
navigation operator (?.), the generated AST String representation
incorrectly omitted the '?' characters.
For example, 'myProperty?.myMethod()' had a generated AST string
representation of 'myProperty.myMethod()'.
This commit addresses this by introducing isNullSafe() in
MethodReference and reworking the logic in
CompoundExpression.toStringAST().
Closes gh-31326
This commit revises the contribution for gh-25921 in the following ways.
- Use instanceof pattern matching
- Use List.of() and Map.of()
- Add missing @since tags
- Polish Javadoc
- Rename isNegativeNumber() to isNegativeNumberLiteral()
- Restructure InlineCollectionTests using @Nested, etc.
- Fix testListWithVariableNotCached() test: it previously set a SpEL
"variable" but tested a "property" in the root context object, which
effectively did not test anything.
- Introduce additional tests: listWithPropertyAccessIsNotCached(),
mapWithVariableIsNotCached(), and mapWithPropertyAccessIsNotCached().
This commit adds support for inlined Kotlin value
class properties in SpEL by leveraging Kotlin
reflection instead of Java reflection broken
by the mangled method name.
Closes gh-30468
Java 12 introduced java.lang.Class#componentType() as a shortcut for
getComponentType().
Since we started using arrayType() in fe5560400c, this commit switches
to componentType() for consistent API usage style.
Prior to this commit, if a Spring Expression Language (SpEL) expression
contained indexed access to an object, the generated AST String
representation incorrectly included a dot ('.') before the index access.
For example, 'property[0]' had a generated AST string representation of
'property.[0]'.
This commit addresses this by reworking the logic in
CompoundExpression.toStringAST().
Closes gh-30610
Prior to this commit, only the letters 'A' - 'Z' (ignoring case) were
supported in identifiers (i.e., property, field, and variable names).
This known (yet undocumented) limitation prevented the use of characters
such as 'ü', 'ñ', 'é' as well as letters from other character sets such
as Chinese, Japanese, Cyrillic, etc.
This commit lifts that restriction by delegating to Character.isLetter()
to determine if a character in a SpEL expression is a letter.
Closes gh-30580
Prior to this commit, when an unsupported character such as "ü" was
encountered in a SpEL expression, the error message was:
Cannot handle (252) 'ü'
With this commit, the error message is now similar to:
Unsupported character 'ü' (252) encountered at position 5 in expression.
See gh-30580
Closes gh-30602
This commit adds support for MethodHandles in SpEL, using the same
syntax as user-defined functions (which also covers reflective Methods).
The most benefit is expected with handles that capture a static method
with no arguments, or with fully bound handles (where all the arguments
have been bound, including a target instance as first bound argument
if necessary). Partially bound MethodHandle should also be supported.
A best effort approach is taken to detect varargs as there is no API
support to determine if an argument is a vararg or an explicit array,
unlike with Method. Argument conversions are also applied. Finally,
array repacking is not always necessary with varargs so it is only
performed when the vararg is the sole argument to the invoked method.
See gh-27099
Closes gh-30045
Prior to gh-30325, supplying a null reference for a SpEL expression was
effectively equivalent to supplying the String "null" as the
expression. Consequently, evaluation of a null reference expression
always evaluated to a null reference. However, that was accidental
rather than by design.
Due to the introduction of the checkExpressionLength(String) method in
InternalSpelExpressionParser (in conjunction with gh-30325), an attempt
to evaluate a null reference as a SpEL expression now results in a
NullPointerException.
To address both of these issues,
TemplateAwareExpressionParser.parseExpression() and
SpelExpressionParser.parseRaw() now reject null and empty SpEL
expressions.
Closes gh-30371
This commit introduces infrastructure to differentiate between
programmatic setting of a variable in an EvaluationContext versus the
assignment of a variable within a SpEL expression using the assignment
operator (=). In addition, this commit disables variable assignment
within expressions when using the SimpleEvaluationContext.
Closes gh-30326
This commit introduces support for limiting the maximum length of a
string resulting from the concatenation operator (+) in SpEL
expressions.
Closes gh-30324
This commit changes the max regex length in SpEL expressions from 1024
to 1000 in order to consistently use "round" numbers for recently
introduced limits.
See gh-30265
This commit increases the max regex length in SpEL expressions from 256
to 1024 in order to support use cases where a regex may be rather long
without necessarily increasing the complexity of the regex.
Closes gh-30265
This commit refactors some AssertJ assertions into more idiomatic and
readable ones. Using the dedicated assertion instead of a generic one
will produce more meaningful error messages.
For instance, consider collection size:
```
// expected: 5 but was: 2
assertThat(collection.size()).equals(5);
// Expected size: 5 but was: 2 in: [1, 2]
assertThat(collection).hasSize(5);
```
Closes gh-30104
Supplying a large regular expression to the `matches` operator in a
SpEL expression can result in errors that are not very helpful to the
user.
This commit improves the diagnostics in SpEL for the `matches` operator
by throwing a SpelEvaluationException with a meaningful error message
to better assist the user.
Closes gh-30144
Attempting to create repeated text in a SpEL expression using the
repeat operator can result in errors that are not very helpful to the
user.
This commit improves the diagnostics in SpEL for the repeat operator by
throwing a SpelEvaluationException with a meaningful error message in
order to better assist the user.
Closes gh-30142
This commit ensures that methods declared in java.lang.Object (such as
toString() can be invoked on a JDK proxy instance in a SpEL expression.
Closes gh-25316
