Description
Davide Pallaoro opened SPR-17614 and commented
Hi there,
I’ve seen that InlineMap class have a nice mechanism that, cache the value of the map if it is constant.
But if the map contains a negative number this caching mechanism is not working.
Take for example the following test
package test;
import org.springframework.expression.Expression;
import org.springframework.expression.ExpressionParser;
import org.springframework.expression.spel.standard.SpelExpressionParser;
import org.testng.Assert;
import org.testng.annotations.Test;
public class MapCacheTest {
@Test
public void testMapCached() {
parseMap("{1 : 2, 3 : 4}");
}
@Test
public void testMapNOTCached() {
parseMap("{-1 : 2, 3 : 4}");
}
private void parseMap(String s) {
ExpressionParser parser = new SpelExpressionParser();
Expression expression = parser.parseExpression(s);
Object value = expression.getValue();
Assert.assertNotNull(value);
}
}
If you run the previous code, (using org.springframework.spring-expression:5.1.3.RELEASE) and set a breakpoint in
org.springframework.expression.spel.ast.InlineMap#getValueInternal
which code is the following..
@Override
public TypedValue getValueInternal(ExpressionState expressionState) throws EvaluationException {
if (this.constant != null) {
return this.constant;
}
else {
Map<Object, Object> returnValue = new LinkedHashMap<>();
int childcount = getChildCount();
for (int c = 0; c < childcount; c++) {
You will notice that when executing MapCacheTest.testMapCached() this.constant is returned.
But when running MapCacheTest.testMapNOTCached() the code jump into the else statement and create a new map each time this method is called.
In a scenario with an high concurrency and with pretty big maps, this could decrease the performance of the app.
Let me know if everything is clear or you need some further details.
Many thanks and kind regards.
Affects: 5.1.3
Issue Links:
- SpEL, error parsing big InlineMap [SPR-17605] #22137 SpEL, error parsing big InlineMap
- Revisit restrictions in SpEL position handling [SPR-17625] #22157 Revisit restrictions in SpEL position handling