putIfAbsent() fast-path race in ConcurrentWeakCache

[elharo]

Affected version: HEAD

File: maven-resolver-util/src/main/java/org/eclipse/aether/util/concurrency/ConcurrentWeakCache.java:124-146

V existing = get(key);  // fast path
if (existing != null) {
    return existing;
}

The fast-path get() uses a ThreadLocal LookupKey. Between get() returning null and merge() at line 135, another thread can insert a new value. The merge correctly handles this, but if get() returns a non-null reference to a key that gets GC'd immediately after, we return a stale reference. This is a correct-by-accident pattern — the merge would fix it, but we return early.

Originally reported in #1944.

[elharo]

The issue reported in apache/maven-resolver #1997 is not a bug. No action should be taken to modify the code, and the issue should be closed as a false positive.

The bug report claims that the fast-path get() operation in ConcurrentWeakCache contains a flaw where it can return a "stale reference" if the key is garbage collected immediately after the check. This claim is technically incorrect and contradicts Java's memory model and garbage collection mechanics for the following reasons:

Strong References Prevent Garbage Collection: The caller of putIfAbsent(K key, V value) provides the key object as a method argument. Because the calling thread holds a strong reference to key on its execution stack, the Java Garbage Collector (GC) cannot collect the key while the method is executing.

Safe Value Retrieval: When the fast-path executes V existing = get(key), the method extracts and returns the value. If the value is found, existing becomes a strong reference on the thread's stack. Once a strong reference is established, the object is protected from garbage collection.

No "Stale" Strong References: Java does not return "stale" strong references. If the underlying data structure uses WeakReference or SoftReference, the act of unwrapping the reference yields either a valid, strong reference to the object or null (if the object was already collected). It is impossible to return a non-null reference that subsequently becomes invalid while still in scope.

The fast-path optimization is correct by design. The issue was labeled as part of an "LLM grabbag" (#1944), indicating it is an automated finding. It is a hallucination of a concurrent race condition that does not exist in the JVM.