René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Jackson 3: comparison/equality operators throw on mismatched or out-of-range operands (e.g. `3.14 = \"abc\"`)","articleBody":"## Summary\n\nAfter the Jackson 3 migration (#430, PR #431), the comparison (`\u003c`, `\u003e`, `\u003c=`, `\u003e=`) and equality (`=`, `in`) operators can throw a raw, uncaught `tools.jackson.databind.node.JsonNodeException` instead of returning a value. In Jackson 2 the underlying `asDouble()`/`asLong()` calls coerced non‑numeric strings to `0.0` and silently narrowed out‑of‑range integers; Jackson 3 made these coercions **fail‑fast** (they throw). The affected call sites are unguarded and their lines were not changed by the migration, so the behavior flipped from \"return a boolean\" to \"crash\".\n\nThis was **not caught by the test suite** — no existing test exercises these mismatched/out‑of‑range operand combinations.\n\n## Where\n\n`src/main/java/com/api/jsonata4java/expressions/ExpressionsVisitor.java`\n\n- `areJsonNodesEqual` (drives `=` and `in`): lines 170–177 — `left.asDouble() == right.asDouble()` and `left.asLong() == right.asLong()`.\n- `\u003c` operator: lines 1327/1329 (`asDouble`), 1331/1333 (`asLong`).\n- `\u003e` operator: lines 1354/1356, 1358/1360.\n- `\u003c=` operator: lines 1381/1383, 1385/1387.\n- `\u003e=` operator: lines 1408/1410, 1411/1414.\n\nIn every case the branch is entered as soon as **one** side is floating‑point (or both are integral), with no check that the **other** side is actually numeric / in range.\n\n## Reproductions\n\n| Expression | Jackson 2 result | Jackson 3 result |\n| --- | --- | --- |\n| `3.14 = \"abc\"` | `false` (valid JSONata) | **throws `JsonNodeException`** |\n| `3.14 in [\"abc\"]` | `false` | **throws** |\n| `3.14 \u003c \"abc\"` | `false` | **throws** |\n| `99999999999999999999 \u003c 5` (integer literal \u003e `Long.MAX_VALUE`) | compared narrowed value | **throws** |\n\nThe `3.14 = \"abc\"` case is the most serious: comparing a number to a non‑numeric string for equality is legal JSONata and must yield `false`, not raise an exception.\n\n## Verified empirically against jackson‑databind 3.2.0\n\n```\nStringNode(\"abc\").asDouble()      -\u003e THROWS JsonNodeException\nStringNode(\"abc\").asLong()        -\u003e THROWS JsonNodeException\nBigIntegerNode(99999999999999999999).asLong() -\u003e THROWS JsonNodeException\n```\n\n## Suggested fix\n\nGuard each numeric branch so the throwing coercion is only reached for actually‑coercible operands (e.g. require both sides numeric before `asDouble()`/`asLong()`, or range‑check with `canConvertToLong()` and fall back to `doubleValue()`/`bigIntegerValue()`), mirroring the guards already added to `MatchFunction`/`ReplaceFunction`/`ArrayUtils.compare` in this migration. Where operand types are genuinely incompatible, throw the controlled `EvaluateRuntimeException` the code already uses for the string/type‑mismatch branches rather than leaking a Jackson exception.\n","author":{"url":"https://github.com/wnm3","@type":"Person","name":"wnm3"},"datePublished":"2026-07-07T16:38:34.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/432/JSONata4Java/issues/432"}