dependabot[bot] opened a new pull request, #20786: URL: https://github.com/apache/camel/pull/20786
Bumps [com.cedarsoftware:java-util](https://github.com/jdereg/java-util) from 4.80.0 to 4.81.0. <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.81.0 - 2025-01-10</h4> <ul> <li><strong>ARCHITECTURE</strong>: <code>CompactMap</code> - Replaced runtime Java compilation with pre-compiled bytecode template <ul> <li><strong>No longer requires JDK</strong>: The builder API (<code>CompactMap.builder().build()</code>) now works on JRE, not just JDK</li> <li><strong>How it works</strong>: A pre-compiled bytecode template is patched at runtime with the configuration hash, then static fields are injected with configuration values (case sensitivity, compact size, ordering, etc.)</li> <li><strong>Performance</strong>: Eliminates JavaCompiler overhead - template classes are created via <code>MethodHandles.Lookup.defineClass()</code> with simple byte array patching</li> <li><strong>Same functionality</strong>: All existing builder options work exactly as before (case sensitivity, ordering, compact size, custom map types, etc.)</li> <li><strong>Backward compatible</strong>: Subclassing <code>CompactMap</code> continues to work unchanged</li> <li>Disabled obsolete <code>CompactMapMethodsTest.testGetJavaFileForOutputAndOpenOutputStream</code> (tested old JavaFileManager approach)</li> </ul> </li> <li><strong>BUG FIX</strong>: <code>Converter</code> - Fixed char[]/byte[] cross-conversion returning null after <code>isConversionSupportedFor()</code> was called <ul> <li>Root cause: <code>VoidConversions::toNull</code> was used as a placeholder in <code>CONVERSION_DB</code> to "advertise" that char[] ↔ byte[] conversions are supported</li> <li>When <code>isConversionSupportedFor(char[].class, byte[].class)</code> was called, this placeholder got cached</li> <li>Subsequent <code>convert(char[], byte[].class)</code> found the cached placeholder and used it, returning null instead of performing actual conversion</li> <li>Fix: Replaced placeholder entries with actual converters that call <code>ArrayConversions.arrayToArray()</code></li> <li>Added tests: <code>testIsConversionSupportedForDoesNotBreakConvert</code>, <code>testArrayCrossConversionWithAndWithoutSupportCheck</code></li> </ul> </li> <li><strong>BUG FIX</strong>: <code>AbstractConcurrentNullSafeMap.computeIfAbsent()</code> - Fixed contention causing hangs under concurrent load <ul> <li>Affects: <code>ConcurrentHashMapNullSafe</code> and <code>ConcurrentNavigableMapNullSafe</code> (both extend AbstractConcurrentNullSafeMap)</li> <li><strong>Root cause</strong>: Used <code>ConcurrentHashMap.compute()</code> which holds a lock on the hash bin for the entire duration of the mapping function execution. Under high concurrency, threads pile up waiting for bin locks, causing hangs.</li> <li><strong>Key insight</strong>: The common case (no null values stored) doesn't need special sentinel handling during computation</li> <li><strong>Fix</strong>: Fast path now delegates directly to <code>ConcurrentHashMap.computeIfAbsent()</code> - this is lock-free for cache hits and only briefly locks for insertions. The slow path (key mapped to null, which is rare) uses optimistic locking with <code>putIfAbsent()</code>/<code>replace()</code>.</li> <li><strong>Result</strong>: Performance is now virtually identical to plain <code>ConcurrentHashMap</code> for typical use cases (caching, memoization, etc.)</li> </ul> </li> <li><strong>TEST FIX</strong>: <code>LRUCacheTest</code> - Added proper cleanup to prevent OutOfMemoryError during deployment tests <ul> <li>The <code>testSpeed</code> and <code>testCacheBlast</code> tests create 10M-entry caches (~800MB each)</li> <li>Added <code>@AfterEach</code> cleanup that clears and nullifies caches, then suggests GC</li> <li>Added explicit <code>cache.clear()</code> at the end of large tests to free memory before next test</li> </ul> </li> <li><strong>IMPROVED</strong>: Scheduler lifecycle management for <code>ThreadedLRUCacheStrategy</code> and <code>TTLCache</code> <ul> <li>Both classes now have proper shutdown methods that await termination (up to 5 seconds graceful, then 1 second forced)</li> <li>Schedulers are now lazily recreatable - if shut down, creating new cache instances automatically restarts them</li> <li><code>ThreadedLRUCacheStrategy.shutdownScheduler()</code> - new static method for explicit cleanup</li> <li><code>TTLCache.shutdown()</code> - now returns boolean indicating clean termination, properly awaits termination</li> <li>All schedulers use daemon threads, so they won't prevent JVM shutdown even without explicit cleanup</li> </ul> </li> <li><strong>IMPROVED</strong>: <code>ThreadedLRUCacheStrategy</code> - Complete algorithm redesign with zone-based eviction and sample-15 approximate LRU <ul> <li><strong>Memory guarantee</strong>: Cache never exceeds 2x capacity, allowing predictable worst-case memory sizing</li> <li><strong>Four-zone eviction strategy</strong>: <ul> <li>Zone A (0 to 1x capacity): Normal operation, no eviction</li> <li>Zone B (1x to 1.5x capacity): Background cleanup only (every 500ms)</li> <li>Zone C (1.5x to 2x capacity): Probabilistic inline eviction (0% at 1.5x → 100% at 2x)</li> <li>Zone D (2x+ capacity): Hard cap with evict-before-insert</li> </ul> </li> <li><strong>Sample-15 eviction</strong>: Instead of sorting all entries O(n log n), samples 15 entries and evicts the oldest. Based on Redis research, this provides ~99% LRU accuracy with O(1) cost per eviction.</li> <li><strong>No more sorting</strong>: Eliminated all O(n log n) sort operations - entire algorithm is now O(1) for inline operations</li> <li><strong>Concurrent race fix</strong>: Zone D eviction now uses a while-loop to guarantee hard cap enforcement. Previously, multiple threads could all check <code>size < hardCap</code>, then all insert, causing unbounded growth (check-then-act race condition). Now inserts first, then loops eviction until under hard cap.</li> <li><strong>Fixes deployment hang</strong>: Heavy write load (500k unique keys into 5k cache) no longer causes hangs due to expensive sorting or unbounded cache growth</li> </ul> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/jdereg/java-util/commit/56134d2711ffa144c5eb7d408404646f89736ef9";><code>56134d2</code></a> ThreadedLRUCacheStrategy: Zone-based eviction with sample-15 approximate LRU</li> <li><a href="https://github.com/jdereg/java-util/commit/c612d517632edaa2474f26485ecd59490eccea17";><code>c612d51</code></a> Docs: Fix Javadoc to use {<a href="https://github.com/code";><code>@code</code></a> } blocks instead of HTML entities</li> <li><a href="https://github.com/jdereg/java-util/commit/8b0a2f2c08e7ce5e477e43faa1525e1dc658e26d";><code>8b0a2f2</code></a> Remove JDK requirement warnings from CompactMap/CompactSet docs</li> <li><a href="https://github.com/jdereg/java-util/commit/acc51a01543afe9745271da35a030f4192f366f2";><code>acc51a0</code></a> Minor formatting cleanup in CompactMap.injectStaticFields()</li> <li><a href="https://github.com/jdereg/java-util/commit/3ce350286b27a4410484d0f58624acb5709ace58";><code>3ce3502</code></a> Refactor CompactMap to use ByteUtilities and ReflectionUtils</li> <li><a href="https://github.com/jdereg/java-util/commit/08b16bdcec5f6296e6cf2f23fd7faa1e2a9abcda";><code>08b16bd</code></a> Simplify CompactSet to always use CompactMap.builder()</li> <li><a href="https://github.com/jdereg/java-util/commit/a0f004c68475d9e628a3e331d4dec50465efa03c";><code>a0f004c</code></a> Replace CompactMap runtime compilation with bytecode template manipulation</li> <li><a href="https://github.com/jdereg/java-util/commit/5d582d2bc394a14550892e38b967b229bfbd5851";><code>5d582d2</code></a> updated date on changelog.md</li> <li><a href="https://github.com/jdereg/java-util/commit/b3e73440f983b6c8a84bb259c1ee037d94e57d00";><code>b3e7344</code></a> update jar size info</li> <li><a href="https://github.com/jdereg/java-util/commit/267b2c676569114e8d5b521a1d71301e8ee7079d";><code>267b2c6</code></a> update jar size</li> <li>See full diff in <a href="https://github.com/jdereg/java-util/compare/4.80.0...4.81.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 merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@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]
