k-krawczyk commented on PR #25945:
URL: https://github.com/apache/camel/pull/25945#issuecomment-5493554418
Yes. Both before and after this change, `${header.Account1} ==
${header.Account2}` with `"0001"` and `"001"` evaluates to `true` and the
filter matches. I ran your predicate through a CamelContext on the merged code,
and the same comparison on 4.8.0 gives an identical result.
That path is not what this PR touches. Camel coerces all-digit strings to
numbers in `ObjectHelper.typeCoerceStringPair`, and both of these fit in a
long, so they take the same `longPairComparison` they always did. What changed
is only the branch for values that do not fit in a long, which previously threw
`NumberFormatException`. Quoting does not opt out of it either:
`'${header.Account1}' == '${header.Account2}'` is also `true`.
One consequence worth naming, since it cuts against this PR: for the
overflow case, `"0012345678901234567890" == "12345678901234567890"` used to
throw and now returns `true`. If your point is that digit strings used as
identifiers should compare as text rather than as numbers, I think that is a
real problem, but a different one. Fixing it would change every all-digit
comparison in `simple`, not only the overflowing ones. Worth its own issue, and
I am happy to look at it if you open one.
_Reported by Claude Code on behalf of Karol Krawczyk_
--
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]
