k-krawczyk opened a new pull request, #26022:
URL: https://github.com/apache/camel/pull/26022
Implements CAMEL-24582.
Simple's `==` favours numeric comparison when both sides are all-digit
strings, so `"0001" == "001"` is `true`. That is intentional and long-standing
(CAMEL-15587), and it is what you want for padded numbers such as the hour from
`${date:now:HH}`. It is not what you want for identifiers like account numbers,
where the leading zeros carry meaning. That was the case reported in
CAMEL-24580.
This adds `equals` and `!equals`, which always compare the two values as
text, alongside `contains`, `startsWith` and `endsWith`, which already work
that way. `==` is unchanged.
```java
// Account1 is "0001" and Account2 is "001"
.filter().simple("${header.Account1} == ${header.Account2}") // true,
compared as numbers
.filter().simple("${header.Account1} equals ${header.Account2}") // false,
compared as text
```
### Two choices worth a second opinion
**`!equals` rather than `notEquals`.** The issue mentions both. The existing
convention is `!contains`, `!startsWith`, `!regex`, with the two-word `not
contains` forms deprecated and logging a warning, so `notEquals` would not
match any current form. Easy to change if you prefer otherwise.
**No `equalsIgnoreCase`.** `==` has `=~` and `contains` has `~~`, so
`equals` without a case-insensitive counterpart is an asymmetry. It is outside
the scope described in the issue, so I left it out rather than expanding on my
own initiative. Happy to add it here or as a follow-up.
### Notes on the implementation
`LanguageHelper.equalsString` and `PredicateBuilder.equalsString` mirror the
existing `startsWith`/`endsWith` pair exactly: both sides go through the type
converter to `String`, then `String.equals`. No new comparison logic, and
`ObjectHelper.typeCoerceEquals` is not involved.
In `SimpleTokenizer` the two new entries required renumbering `KNOWN_TOKENS`
from index 44 onwards and bumping `NUMBER_OF_TOKENS`. The `minusValue` token
stays last, as its comment requires, so unary `--` keeps its priority.
One thing I checked rather than assumed, since `equals` is a common English
word: a binary operator only tokenises when it is surrounded by spaces
(`evalSurroundedBySpace`), and `SimpleExpressionParser` does not accept
`binaryOperator` tokens at all, so `equals` inside OGNL
(`${header.foo.equals(x)}`) and in plain expression text both stay untouched.
There is a test for the second case.
### Testing
- `SimpleOperatorTest`: 58 tests pass, 3 of them new (`testEquals`,
`testNotEquals`, `testEqualsAsLiteralText`).
- Wider regression across the grammar (`Simple*Test`, `*Predicate*Test`,
`TypeCoerce*Test`, `ObjectConverter*Test`, `ObjectHelperTest`,
`Tokenizer*Test`): 818 tests, no failures.
- `formatter:validate` and `impsort:check` are clean under `-Psourcecheck`.
No upgrade guide entry: this only adds operators, and existing behaviour is
untouched.
_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]
