dependabot[bot] opened a new pull request, #24484: URL: https://github.com/apache/camel/pull/24484
Bumps [com.cedarsoftware:java-util](https://github.com/jdereg/java-util) from 4.106.0 to 4.107.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/jdereg/java-util/releases";>com.cedarsoftware:java-util's releases</a>.</em></p> <blockquote> <h2>4.107.0</h2> <h2>java-util 4.107.0</h2> <p><strong>Performance (concurrency) — removed the dominant multi-threaded deserialization lock.</strong> <code>ClassUtilities.trySetAccessible</code> probed a <code>Collections.synchronizedMap(WeakHashMap)</code> on <strong>every</strong> object instantiation and field injection. Under concurrent load that single monitor serialized worker threads — 13-thread profiling of concurrent json-io reads showed <strong>~74% of threads BLOCKED</strong> on it. It's now a lock-free <code>ConcurrentHashMap</code>; post-change profiling shows <strong>zero</strong> threads blocked. Single-threaded performance is unchanged. This directly improves json-io's concurrent read scaling.</p> <p><strong>Performance —</strong> <code>ReflectionUtils.getAllConstructors(Class)</code> no longer allocates on a cache hit. It's now keyed directly by <code>Class</code> with a <code>get()</code>-first fast path (no per-probe key allocation, no capturing compute lambda on hits); the redundant <code>SortedConstructorsCacheKey</code> wrapper was removed. Anti-poisoning/security semantics are unchanged.</p> <p><strong>Documentation —</strong> <code>ClassValueMap</code> / <code>ClassValueSet</code> Javadoc, <code>userguide.md</code>, and <code>README.md</code> now document their critical usage constraints. They are <strong>specialists</strong> for a <em>few, pre-populated, read-mostly</em> class registries — not general-purpose faster <code>Map<Class,V></code> / <code>Set<Class></code>. The docs now cover: the <strong>non-local cost</strong> (every <code>Class</code> has one small, <code>PROBE_LIMIT</code>-bounded ClassValue cache array shared across <em>all</em> <code>ClassValue</code> instances, so many instances thrash each other and the advantage inverts past ~10); that <strong>lazy get-then-<code>put</code> population is an anti-pattern</strong> (<code>put()</code> invalidates the whole ClassValue → ≈O(N²) warm-up); and that the <strong>strong-referencing backing store forfeits <code>ClassValue</code>'s leak-safety</strong>. No behavioral change.</p> <hr /> <p>Full changelog: <a href="https://github.com/jdereg/java-util/blob/master/changelog.md";>https://github.com/jdereg/java-util/blob/master/changelog.md</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/jdereg/java-util/blob/master/changelog.md";>com.cedarsoftware:java-util's changelog</a>.</em></p> <blockquote> <h4>4.107.0 - 2026-07-06</h4> <ul> <li><strong>DOCUMENTATION</strong>: <code>ClassValueMap</code> and <code>ClassValueSet</code> Javadoc, <code>userguide.md</code>, and <code>README.md</code> now document the critical usage constraints uncovered by profiling. These are <strong>specialists</strong>, not general-purpose faster <code>Map<Class,V></code>/<code>Set<Class></code>: they win only for a <em>few, pre-populated, read-mostly</em> class registries. The docs now spell out (1) the <strong>non-local cost</strong> — every <code>Class</code> has one small, <code>PROBE_LIMIT</code>-bounded ClassValue cache array shared across <em>all</em> <code>ClassValue</code> instances, so many instances keyed on the same classes thrash each other and the "faster than <code>ConcurrentHashMap</code>" advantage inverts past ~10; (2) that <strong>lazy get-then-<code>put</code> population is an anti-pattern</strong> because <code>put()</code> invalidates the whole ClassValue (≈O(N²) as classes warm up); and (3) that the <strong>strong-referencing backing store forfeits <code>ClassValue</code>'s leak-safety</strong>. No behavioral change.</li> <li><strong>PERFORMANCE (concurrency)</strong>: <code>ClassUtilities.trySetAccessible</code> no longer serializes concurrent callers on a single lock. Its <code>accessibilityCache</code> was a <code>Collections.synchronizedMap(WeakHashMap)</code> probed on <strong>every</strong> object instantiation and field injection; under multi-threaded deserialization this monitor was the dominant contention point — 13-thread profiling of concurrent json-io reads showed ~74% of worker threads BLOCKED on it, and after the change profiling shows zero threads blocked on it. It is now a lock-free <code>ConcurrentHashMap</code>. The map only ever stores failures (members whose module refuses to open — JPMS-sealed platform/JDK internals on the bootstrap loader, which are never unloaded), so dropping the weak keys retains no application or dynamically-loaded (e.g. Groovy) classloaders; caching logic is otherwise unchanged. Single-threaded performance is unchanged.</li> <li><strong>PERFORMANCE</strong>: <code>ReflectionUtils.getAllConstructors(Class)</code> no longer allocates on a cache hit. It previously wrapped the class in a <code>SortedConstructorsCacheKey</code> on every call just to probe the cache, and passed a capturing compute lambda that was allocated at the call site even when unused — both per-object costs on hot reflection/deserialization paths (e.g. json-io's per-instance construction). The cache is now keyed directly by <code>Class</code> (which already has identity <code>equals</code>/<code>hashCode</code>, so the anti-poisoning/security semantics are unchanged), with a <code>get()</code>-first fast path that allocates nothing on hits; the redundant <code>SortedConstructorsCacheKey</code> class was removed.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/jdereg/java-util/commit/49c02ccf9beee94dd2f4e57c99e4a5e9c897b0ce";><code>49c02cc</code></a> Build: bump json-io test dependency 4.105.0 -> 4.106.0</li> <li><a href="https://github.com/jdereg/java-util/commit/1930f38790217e9687c16b47d86fe7393ab51aad";><code>1930f38</code></a> Documentation: scope ClassValueMap/ClassValueSet to their niche + document th...</li> <li><a href="https://github.com/jdereg/java-util/commit/7192c0e552035b5e02196b196eae81dc4a5fa0da";><code>7192c0e</code></a> Performance: lock-free ClassUtilities.accessibilityCache (removes concurrent-...</li> <li><a href="https://github.com/jdereg/java-util/commit/36101fd5477c575f3d55585c162f323596c04ae7";><code>36101fd</code></a> Performance: ReflectionUtils.getAllConstructors keyed by Class (drop per-prob...</li> <li>See full diff in <a href="https://github.com/jdereg/java-util/compare/4.106.0...4.107.0";>compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> 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) </details> -- 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]
