allthingssecurity opened a new pull request, #26873: URL: https://github.com/apache/camel/pull/26873
# Description [CAMEL-25013](https://issues.apache.org/jira/browse/CAMEL-25013) `ObjectHelper.typeCoerceCompare` has fast paths for two `Integer`, `Long`, `Double` or `Float` values. Any other pair of numbers, for example a `Double` or `BigDecimal` against an integer literal, or two `BigDecimal` values, falls through to converting both sides to `Long`. That conversion drops the fractional part, and wraps a `BigInteger` that doesn't fit in a long. `typeCoerceEquals` converts the left value to the right value's type, which has the same effect. These methods back every Simple comparison operator (`>`, `>=`, `<`, `<=`, `==`, `!=`, `range`, `in`) and the Java DSL predicates (`header("x").isGreaterThan(...)` and similar). Values from JSON are usually `Double` and values from JDBC are usually `BigDecimal`, and they are commonly compared with integer literals. The result is wrong routing with no error: ```java from("direct:order").choice() .when(simple("${header.amount} > 100")).to("direct:large") // amount = BigDecimal 100.50 -> otherwise .otherwise().to("direct:small"); ``` Other examples: - `${header.price} == 2` is true for a `Double` 2.5, and `${header.price} range '1..2'` is true for it too; - `BigDecimal 2.5 > BigDecimal 2.4` is false. The same fallback code is in 2.25, 3.0 and 4.x. This change: - `typeCoerceCompare` now compares two numbers, or a number and a numeric `String`, by value, after the existing fast paths, which are unchanged. Two integral values are compared as `long`. Anything else is compared as `BigDecimal`: `Double` and `Float` go through their decimal representation, so `0.1f` equals `0.1d`; NaN and infinity are compared as `double`, and infinity is still above any finite value, even one too large for a `double`. - `typeCoerceEquals` does the same for two numbers of different types, and for two `BigDecimal` values, because `BigDecimal.equals` also compares the scale: `2.50 == 2.5` used to be false while `<=` and `>=` were both true. - `2.0 == 2` and `2 < 2.5` behave as before. - Upgrade guide: a bullet in the existing 4.23 list of Simple language edge cases, because existing routes can now get a different result. Tests: - `TypeCoerceCompareTest`: numbers of different types with decimals, two `BigDecimal`/`BigInteger` values, infinity against huge values, and equality. - `SimpleOperatorTest.testCompareDecimalWithInteger`: `>`, `==`, `!=`, `<=` and `range` with `BigDecimal` and `Double` headers against integer literals. All three new tests fail without the change. For example `${header.amount} > 100` is false and `typeCoerceCompare(2.5d, 2)` is 0. With the fix, `TypeCoerce*,*Simple*,*Predicate*,*ObjectHelper*,*Filter*,*Choice*,*Compar*,*Sort*,*Converter*,*Range*,*Validat*,*Mock*` in camel-core pass: 1653 tests, 0 failures. Found with a Lean model of the comparison. It proves that for every n ≥ 0 and every digit d from 1 to 9, the old code treats n.d as equal to n, and that whole numbers always compare correctly. I then reproduced the bug against the real classes. A property-based test (jqwik, 3000 random `Double`/`BigDecimal` vs `Integer` pairs per property) shrinks the failure on main to `0.01` vs `0` comparing as equal, and passes with this change. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested the affected modules, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
