chore(deps): Bump com.cedarsoftware:java-util from 4.109.0 to 4.110.0

[dependabot]

Bumps com.cedarsoftware:java-util from 4.109.0 to 4.110.0.

Release notes

Sourced from com.cedarsoftware:java-util's releases.

4.110.0

java-util 4.110.0

Maven Central: com.cedarsoftware:java-util:4.110.0

Three conversion correctness fixes, all found while building decision-table type inference in n-cube — which asks the Converter whether a value survives a type change, and could not trust the answers.

Conversion correctness

"yes" converted to false. The truth set accepted "true", "t", "1" and "y" — but not the spelled-out word. So "y" was true while "Yes" was false. Not a rejection but an inversion, and a silent one, since anything unrecognised returns false rather than throwing: text written the long way read as the exact opposite of what it said. "yes" now joins "y", case-insensitively.

Float → Double and Float → BigDecimal widened through the bits. 3.7f became 3.700000047683716; 0.1f became 0.10000000149011612. Widening now goes through Float.toString(), which emits the shortest decimal that uniquely identifies the float, so 3.7f becomes 3.7. Nothing is lost — every value still converts back to the identical float, extremes included; only which of the doubles mapping to that float you land on changes, and the one that prints as the float prints is the one that was meant. BigDecimal was the worse case: a type whose whole purpose is exact decimal representation was being handed the binary error.

BigDecimal → String stripped the scale. new BigDecimal("1.50") rendered as "1.5", so BigDecimal → String → BigDecimal returned a value not equals() to the original — BigDecimal equality includes scale. Scale is information: it separates an amount written to the cent from the same quantity written to the tenth. Now toPlainString(), which keeps the scale and still never emits scientific notation.

Behaviour changes to be aware of

• Float.MAX_VALUE → Double is now 3.4028235E38 rather than 3.4028234663852886E38.
• Any caller rendering a BigDecimal through the Converter now sees trailing zeros preserved.

Integral targets are unaffected — Float/Double/BigDecimal → Long/BigInteger still truncate, which is inherent to discarding a fraction. DeepEquals deliberately still normalises trailing zeros, because comparison should treat 1.50 and 1.5 as equal even though rendering should not.

Testing

The performRelease benchmarks now detect regressions instead of printing numbers nobody compares, and the four slowest test classes got 9x faster — roughly 80 seconds of every release build sat in tests with no assertions at all. See the changelog for the full account.

Build

maven-jar-plugin 3.5.0 → 3.5.1, maven-bundle-plugin 6.0.2 → 6.1.0. JUnit (5.14.4), Mockito (4.11.0) and agrona (1.23.1) are each already the newest release in the series their JDK 8 support pins them to.

---

20,411 tests green. Verified against json-io's full suite (4,748 tests) before publishing.

Changelog

Sourced from com.cedarsoftware:java-util's changelog.

4.110.0 - 2026-08-02

• CONVERSION (correctness): Converter.convert() silently inverted "Yes" and silently mangled every Float. Both were found while building decision-table type inference in n-cube, which asks the Converter whether a value survives a type change; it could not trust either answer.
  • "yes"/"Yes"/"YES" converted to false. The truth set accepted "true", "t", "1" and "y" — but not the spelled-out word. So "y" was true while "Yes" was false: not a rejection, an inversion, and a silent one, since anything unrecognised returns false rather than throwing. Any data written the long way read as the opposite of what it said, which for the No/Yes answers commonly held in decision-table output columns would have flipped every affirmative. "yes" now joins "y", case-insensitively; "no" was already false (though only because everything unmatched is).
  • Float → Double and Float → BigDecimal widened through the bits instead of the decimal. 3.7f became 3.700000047683716 and 0.1f became 0.10000000149011612, because Float.doubleValue() faithfully preserves the binary approximation rather than the number the author wrote. Widening now goes through Float.toString(), which by contract emits the shortest decimal that uniquely identifies the float, so 3.7f becomes 3.7. Nothing is lost: every value still converts back to the identical float, including Float.MIN_VALUE and Float.MAX_VALUE; what changes is only which of the doubles that map back to that float you land on, and the one that prints as the float prints is the one that was meant. BigDecimal was the worse of the two — a type whose entire purpose is exact decimal representation was being handed the binary error. Behaviour change at the extremes: Float.MAX_VALUE → Double is now 3.4028235E38 rather than 3.4028234663852886E38. The Float→BigDecimal test cases had been chosen as exactly-representable values with the comment "Changed to avoid float precision issues" — the defect was being worked around rather than reported.
  • Integral targets are unaffected: Float/Double/BigDecimal → Long/BigInteger still truncate, which is inherent to discarding a fraction.
  • New cases live in the shared ConverterEverythingTest table, so they are exercised through every path — direct conversion, JSON-IO round-trip, and TOON.
  • BigDecimal → String no longer strips the scale. It called stripTrailingZeros() first, so new BigDecimal("1.50") rendered as "1.5" — which broke round-tripping, because BigDecimal equality includes scale, so BigDecimal → String → BigDecimal returned a value not equals() to the original. Scale is information: it is what separates a money amount written to the cent from the same quantity written to the tenth. Now toPlainString(), which keeps the scale and still never emits scientific notation — the property the old implementation was really relying on. Behaviour change: any caller rendering a BigDecimal through the Converter now sees trailing zeros preserved. The blast radius is exactly one registration; nothing else reaches this method, and the stripTrailingZeros() in DeepEquals is deliberately untouched because comparison should treat 1.50 and 1.5 as equal even though rendering should not.
• BUILD: maven-jar-plugin 3.5.0 → 3.5.1, maven-bundle-plugin 6.0.2 → 6.1.0. JUnit (5.14.4), Mockito (4.11.0) and agrona (1.23.1) are each already the newest release in the series their JDK-8 support pins them to; json-io stays one release behind (4.108.0) by the trail-by-one rule that keeps the two projects from cycling.
• TESTING: The performRelease benchmarks now detect performance regressions instead of printing numbers nobody compares — and the four slowest test classes got 9x faster. They previously burned ~110 seconds of every release build, and roughly 80 of those seconds sat in tests with no assertions at all: they could not fail, could not detect a regression, and produced absolute millisecond figures that are not comparable between a dev laptop, a CI runner, and the release machine. A human had to read the log and remember last release's numbers.
  • New PerfRatchet test harness records each benchmark as a ratio against a yardstick workload measured in the same JVM run, interleaved trial-for-trial — CaseInsensitiveMap against the LinkedHashMap it wraps, Cedar's MultiKeyMap against Apache Commons', the caches against HashMap/LinkedHashMap. Machine speed divides out, so 1.85x means "1.85 times the cost of the JDK equivalent" on any hardware. 19 metrics are tracked in src/test/resources/perf-baseline.properties.
  • Nothing fails the build. Verdicts are OK / IMPROVED / REGRESSED / NEW, logged and written to target/perf-report.tsv; a regression is a WARNING, not a test failure, because turning normal variance into a red build is how a perf signal gets ignored. -Dperf.strict=true opts into failing, for a machine whose numbers you trust.
  • The ratchet locks in gains. -Dperf.baseline.update=true writes improvements back and never writes a regression, so the bar only moves toward faster. -Dperf.baseline.reset=true writes every metric in either direction, because a pure ratchet cannot repair itself — a baseline first captured from an unluckily fast reading would report a regression forever and update mode by definition will not raise it back.
  • Self-calibrating bars. Each metric publishes the interquartile scatter of its own trials, and the regression/improvement bar is the configured floor or that scatter, whichever is larger. A metric whose trials disagreed by 35% cannot credibly report a 25% change; one that measured to 3% is held to the tight floor. This is what lets noisy allocation-heavy benchmarks coexist with precise ones without slackening the threshold for everybody. An improvement must also clear the noise floor before it can be ratcheted in, so a lucky outlier cannot move the bar out of reach.
  • Measurement fixes found along the way. Warmup must cover every variant sharing a lambda body before any is measured (PerfRatchet.warmAll), or whichever runs first absorbs the JIT cost for all of them — that artifact alone was inflating one metric's noise from ~10% to 63%. Baselines must be calibrated from a full suite run: the same metrics scattered 2-15% in isolation and 5-68% alongside the other ~20,000 tests. LRUCache's THREADED strategy is deliberately not tracked — its ratio ranged 1.14x-3.48x across identical runs because a background cleanup thread services its reads, and that variance is invisible within a single run, so it would report confident regressions on nothing but thread scheduling.
  • CaseInsensitiveMapTest 53.1s → 0.63s. testPerformance/testPerformance2 copied a 10,000-entry map 100,000 times each — two billion entry copies — to print four numbers. They were already a matched CaseInsensitiveMap-vs-LinkedHashMap pair; they simply never divided one by the other. Separately, testCaseInsensitiveMapPerformanceComparison ran every workload twice: timeMapOperations for a fixed 2000 ms, then countOps — a byte-for-byte copy of it plus a counter — for another 2000 ms. Since the loop budget was 2000 ms, the "time" it measured was always ≈2000 by construction, which is why every line of its output read "operations in 2,000 ms". Half that test's 24 seconds computed a constant.
  • MultiKeyMapPerformanceComparisonTest 25.1s → 0.90s. A 6x7 matrix up to 250,000 entries, ten iterations, both implementations: ~105 million map operations, plus a Thread.sleep(100) and an explicit System.gc() per configuration (4.2 seconds of sleeping, 42 forced collections). Two of the seven data sizes accounted for 80% of the work while adding nothing the smaller sizes did not show.
  • LRUCacheTest 21.8s → 7.5s. testCacheBlast put 10,000,000 entries per strategy into a 1000-entry cache — 99.99% evicted on arrival — to assert one number; 200,000 puts is still 200x capacity. testSpeed put another 10,000,000 per strategy (~800MB each, per its own comment) and asserted nothing. The @AfterEach System.gc() meant ~60 forced full collections across the class and is gone.
  • TTLCacheTest 10.1s → 2.7s. 9.4 of its 10.1 seconds were Thread.sleep. One test already demonstrated the fast idiom (200ms TTL, 100ms purge, 350ms wait) while four others used 10x larger values to prove the same properties; they now match. Total sleep is 1.9s.
  • Two findings worth knowing. CaseInsensitiveMap(TreeMap) is ~1.2-1.3x slower than plain TreeMap(String.CASE_INSENSITIVE_ORDER) — you pay for key wrapping and case-insensitive comparison — so a sorted case-insensitive map is better served by the JDK directly; the HashMap/LinkedHashMap-backed variants are 3x and 7x faster than that same TreeMap. And CaseInsensitiveMap's copy constructor runs at parity (~1.0x) with LinkedHashMap's, confirming the CaseInsensitiveString key-reuse optimization pays off. Both are now tracked.
  • scripts/extract-perf-results.sh renders the tracked metrics from the TSV, since the summary block is printed by a JVM shutdown hook that fires after Surefire stops capturing stdout and so never reaches the deploy log. No production code changed — this is test infrastructure only. Suite green: 20,380 tests (release mode), 20,377 (normal).

Commits

• f6b1400 Docs: state the 4.110.0 discovery context without naming the customer
• 223b045 Fix: BigDecimal -> String dropped the scale, so it could not round-trip
• 2e7e0cb Release: java-util 4.110.0
• ad4eb50 Fix: Converter turned "Yes" into false, and widened every Float through its bits
• 8be0815 Test: performance benchmarks now detect regressions, and run 9x faster
• 3ea139b Fix: perf-results script reported nothing on macOS
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• parent

✅ POM dependency changes: targeted tests included

Changed properties: java-util-version

Modules affected by dependency changes (1)

• :camel-headersmap

---

🔬 Scalpel shadow comparison — Scalpel: 9 tested, 29 compile-only — current: 0 all tested

Maveniverse Scalpel detected 38 affected modules (current approach: 0).

⚠️ Modules only in Scalpel (38)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-headersmap
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-mcp
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-mcp
• camel-jbang-plugin-route-parser
• camel-jbang-plugin-test
• camel-jbang-plugin-tui
• camel-jbang-plugin-validate
• camel-kamelet-main
• camel-launcher
• camel-launcher-container
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• camel-yaml-dsl-validator
• camel-yaml-dsl-validator-maven-plugin
• coverage
• docs
• dummy-component

Changed properties: java-util-version

Skip-tests mode would test 9 modules (1 direct + 8 downstream), skip tests for 29 (generated code, meta-modules)

Modules Scalpel would test (9)

• camel-headersmap
• camel-jbang-mcp
• camel-jbang-plugin-mcp
• camel-jbang-plugin-route-parser
• camel-jbang-plugin-tui
• camel-jbang-plugin-validate
• camel-launcher-container
• camel-yaml-dsl-validator
• camel-yaml-dsl-validator-maven-plugin

Modules with tests skipped (29)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-test
• camel-kamelet-main
• camel-launcher
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• coverage
• docs
• dummy-component

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

All tested modules (39 modules)

• Camel :: All Components Sync point
• Camel :: Assembly
• Camel :: Catalog :: CSimple Maven Plugin (deprecated)
• Camel :: Catalog :: Camel Catalog
• Camel :: Catalog :: Camel Report Maven Plugin
• Camel :: Catalog :: Camel Route Parser
• Camel :: Catalog :: Console
• Camel :: Catalog :: Dummy Component
• Camel :: Catalog :: Lucene (deprecated)
• Camel :: Catalog :: Maven
• Camel :: Catalog :: Suggest
• Camel :: Component DSL
• Camel :: Coverage
• Camel :: Docs
• Camel :: Endpoint DSL
• Camel :: Endpoint DSL :: Support
• Camel :: Headers Map (deprecated)
• Camel :: Integration Tests
• Camel :: JBang :: Core
• Camel :: JBang :: Integration tests
• Camel :: JBang :: MCP
• Camel :: JBang :: Main
• Camel :: JBang :: Plugin :: Edit
• Camel :: JBang :: Plugin :: Generate
• Camel :: JBang :: Plugin :: Kubernetes
• Camel :: JBang :: Plugin :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Testing
• Camel :: JBang :: Plugin :: Validate
• Camel :: Kamelet Main
• Camel :: Launcher
• Camel :: Launcher :: Container
• Camel :: Parent
• Camel :: YAML DSL
• Camel :: YAML DSL :: Deserializers
• Camel :: YAML DSL :: Maven Plugins
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results