Doc: SpEL behavior when comparing value to null [SPR-14361]

[spring-projects-issues]

Marko Talijanac opened SPR-14361 and commented

When in SpEL a number is compared to null, a result is interpreted as "null is always the lowest number". Behavior is unexpected and undocumented.

As null is not a number expected behavior would be either exception or false in all cases except when comparing with other null value.

For example expression "x == null && x < 100" should always yield false (or raise exception) as x is either null or a number with a value.

Behavior is not overridable with user provided TypeComparator (except by throwing exception from TypeComparator) as operators never invoke TypeComparator#canCompare method, and always flatten comparator result of (-1,0,1) to true|false result.

Also current behaviour is not consistent with past spring versions. See this stack overflow question

{{examples of popular comparisons
null == null => true

null < 1 => true
1 > null => true
null <= 1 => true
1 >= null => true

null < -1 => true
-1 > null => true
null <= -1 => true
-1 >= null => true

null > 1 => false
1 < null => false
null >= 1 => false
1 <= null => false

null > -1 => false
-1 < null => false
null >= -1 => false
-1 <= null => false}}

---

Affects: 3.2.16, 4.3 GA

Issue Links:

• Spring SpEL - behavioural inconsistency when using greater than (>) operator in an expression [SPR-7840] #12496 Spring SpEL - behavioural inconsistency when using greater than (>) operator in an expression
• SpEL and Date Literals [SPR-14987] #19553 SpEL and Date Literals

Referenced from: commits 6bdc5bf, 05579fd, 5ccc8e3, c22cad1

Backported to: 4.2.9, 3.2.18

[spring-projects-issues]

Marko Talijanac commented

Suggestion are:

• document current behavior
• implement behavior "compare with null always yields false"
• allow user to override operator behavior

[spring-projects-issues]

Juergen Hoeller commented

This seems to have been an intentional change back in 3.1: #12496. Andy Clement, assigning this to you for further clarification.

From my perspective, let's rather document the behavior as it is, since the change of behavior was actually between 3.0 and 3.1... far back.