[
https://issues.apache.org/jira/browse/CAMEL-26329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-26329 started by shashank.
----------------------------------------
> camel-support - Simple == compares a number and a numeric String as text when
> they are written differently: ${header.amount} == '10' is false for a
> BigDecimal 10.00 while <= and >= are true
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26329
> URL: https://issues.apache.org/jira/browse/CAMEL-26329
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
>
> Since CAMEL-25013 (4.23.0) the Simple comparison operators compare two
> numbers, or a number and a numeric String, by their values, and the 4.23
> upgrade guide entry lists "a number compared with a numeric {{String}}" among
> them (its examples include {{==}}). {{ObjectHelper.typeCoerceCompare}} does
> that, but {{typeCoerceEquals}} only got the number/number case. For a number
> and a numeric String that are not written the same way, {{==}} still converts
> the String to the type of the number and uses {{equals}}
> ({{BigDecimal.equals}} also compares the scale), or converts the number to a
> String and compares the text. So {{==}} and {{!=}} disagree with {{<=}} and
> {{>=}} (main aa63c0a4cb94):
> {code}
> amount = BigDecimal 10.00 (for example a DECIMAL(10,2) column read with
> camel-sql)
> ${header.amount} <= '10' true
> ${header.amount} >= '10' true
> ${header.amount} == '10' false
> ${header.amount} == ${header.s} false, for a String header s = "10"
> text = String "10.00"
> ${header.text} == 10 false (<= and >= are true)
> count = Integer 3
> ${header.count} == '3.0' false
> ${header.count} in '3.0' true (in compares the values since CAMEL-25013)
> {code}
> The {{==}} result is the same in older versions; since 4.23 it disagrees with
> the other operators, which compare the values.
> {{simple-operators.adoc}} shows {{simple("$\{header.bar} == '100'")}} as the
> way to compare a header with a number, so a {{choice()}} on a BigDecimal
> amount with a scale takes the wrong branch without an error. The same happens
> for {{Integer}}, {{Long}}, {{Short}} and {{BigInteger}} values compared with
> {{'1e1'}} or {{' 10'}} (with spaces). A {{Double}} or {{Float}} is not
> affected, because the String is converted to a double first.
> *Fix* (proposed): in {{typeCoerceEquals}}, when one side is a number other
> than a double or float and the other side is a String that parses as a
> {{BigDecimal}} (ignoring leading and trailing spaces, as the {{in}} operator
> does), compare them with the same {{compareNumbers}} that
> {{typeCoerceCompare}} uses. {{typeCoerceCompare}} parses the String the same
> way, so {{<}} and {{>}} with {{" 9007199254740992"}} or {{1e0}} are exact and
> no longer compared as doubles. The text is checked to have the form of a
> number before it is parsed (so text such as {{-}} or {{2026-10-26}} is not
> handed to the BigDecimal parser), and text longer than 1000 characters is not
> parsed: parsing a BigDecimal takes time that grows with the square of the
> number of digits (a million digits take about 12 s). Text that is not a
> number, null, two Strings, and doubles are unchanged. A 4.24 upgrade guide
> entry describes the change, as {{==}} and {{!=}} give different results than
> in 4.23 for these values (also {{=~}}, {{contains}} on a collection, and the
> Java DSL and mock predicates).
> *Tests*: {{TypeCoerceCompareTest}} (4 new methods) and
> {{SimpleOperatorTest.testEqualsNumberWithNumericTextWrittenDifferently}} fail
> on main and pass with the change. A differential fuzz harness of the Simple
> numeric operators (5 million inputs, typed headers vs quoted, unquoted and
> header right sides, compared with the comparison of the values) found 1,829
> wrong results on main, all {{==}}/{{!=}} of a number and a numeric String
> written differently; with the change there are none, and no other input
> changes its result.
> *How it was found*: a fuzz harness that checks the Simple comparison
> operators against each other ({{==}} must agree with {{<=}} and {{>=}} both
> being true) on 5 million generated number and text pairs, run on HotSpot; all
> 1 829 disagreements came from this one cause, and none remains with the fix.
> *Affected*: 4.23.0 and main. The fix builds on the value comparison of
> CAMEL-25013, which the older branches do not have, so this follow-up is for
> main only.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
