[CAMEL-21109] Choice evaluation behaves inconsistently when source is String and Value is Float.

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 3.x
• Fix Version/s: 3.22.3, 4.4.4, 4.8.0
• Component/s: camel-core
• Estimated Complexity: Unknown
• Assignee: Claus Ibsen
• Reporter: Harish Annamalai
• Created: 22/Aug/24 10:47
• Updated: 26/Aug/24 07:51
• Resolved: 26/Aug/24 07:51

Description

Choice evaluation works inconsistently if the condition contains Predicates with String, but the value is float.

Consider the choice expression:

${exchangeProperty.left} >= ${exchangeProperty.right}

If the both the properties are 'left' and 'right', but value contained in them is float like '4.0' '7.5' etc, the expression is compared as Strings and returns false. However, if the value contained in them is "Pure" Integer, then they are compared as "Numbers" and Comparision returns true.

Please see the Examples:

Example 1:

        from("timer:getter?period=1000&repeatCount=1")
                .setProperty("left", simple("40"))
                .setProperty("right", simple("7.5"))
                .choice()
                .when(simple("${exchangeProperty.left} >= ${exchangeProperty.right}"))
                .to("log://match")
                .otherwise()
                .to("log://otherwise")
                .end();
                
The Predicate in Example 1, evaluation returns false for the case above as it compares 40 and 7.5 as Strings.

Example 2:                
        from("timer:getter?period=1000&repeatCount=1")
                .setProperty("left", simple("40"))
                .setProperty("right", simple("7"))
                .choice()
                .when(simple("${exchangeProperty.left} >= ${exchangeProperty.right}"))
                .to("log://match")
                .otherwise()
                .to("log://otherwise")
                .end();
                
The Predicate in Example 2, evaluation returns true for the case above as it compares 40 and 7 as Numbers.

 

We debugged the Camel Code, and compared the behavior against Camel 2x, we can see that the predicate evaluation takes "Double" also into consideration.

Camel 2x Code:
ObjectHelper.java

public static int typeCoerceCompare(TypeConverter converter, Object leftValue, Object rightValue) {

        // if both values is numeric then compare using numeric
        Long leftNum = converter.tryConvertTo(Long.class, leftValue);
        Long rightNum = converter.tryConvertTo(Long.class, rightValue);
        if (leftNum != null && rightNum != null)

{             return leftNum.compareTo(rightNum);         }

        // also try with floating point numbers
        Double leftDouble = converter.tryConvertTo(Double.class, leftValue);
        Double rightDouble = converter.tryConvertTo(Double.class, rightValue);
        if (leftDouble != null && rightDouble != null)

{             return leftDouble.compareTo(rightDouble);         }

  

Camel 3x Code:
ObjectHelper.java

public static int typeCoerceCompare(TypeConverter converter, Object leftValue, Object rightValue) {

        // optimize for common combinations of comparing numbers
        if (leftValue instanceof String && rightValue instanceof String) {
            String leftNum = (String) leftValue;
            String rightNum = (String) rightValue;
            if (isNumber(leftNum) && isNumber(rightNum))

{                 // favour to use numeric comparison                 Long num1 = Long.parseLong(leftNum);                 Long num2 = Long.parseLong(rightNum);                 return num1.compareTo(num2);             }

            return leftNum.compareTo(rightNum);
        } else if (leftValue instanceof Integer && rightValue instanceof Integer) {

Issue Links

• links to: GitHub Pull Request #15281