Changed behavior of returned empty maps from LocalAsyncCache

[mranders-hltv]

The change of LocalAsyncCache#composeResult, which swaps Collections.emptyMap() for Map.of() has resulted in changed behavior of the returned maps.

Collections.emptyMap() does allow looking up null keys (resulting in null values), while Map.of() returns Javas MapN, which throws an exception when null is looked up (source below):

public V get(Object o) {
  if (size == 0) {
    Objects.requireNonNull(o);
    return null;
  }
  <SNIP>

This means that the following code fails with an exception when using Caffeine 3.1.2, instead of getting null from the map.

LoadingCache<Object, Object> loadingCache = Caffeine.newBuilder().buildAsync(key -> key).synchronous();
Map<Object, Object> loaded = loadingCache.getAll(Collections.emptyList());
loaded.get(null); //Exception

Even though Map#get does not guarantee that null keys can be used, Caffeine does not allow looking up null keys, and LoadingCache#getAll explicitly states that the returned map "will never contain null keys or values", it is still a small but subtle change in behavior, which can cause runtime problems for users. Especially because it only occurs in the combination of a cache lookup of an empty Iterable, and a lookup of a null key in the returned Map.

[ben-manes]

oh, good catch. I knew of that annoying difference, but forgot at the time. I'll restore this and add unit tests to assert the null lookup behavior.

[ben-manes]

I looked into adding unit tests for this case, but I believe it is already covered by LoadingCacheTest.refresh_expired. In that variant the entry expires before the reload completes, which results in it being evicted and the refresh discarded. That's an explicit refresh, but an automatic one behaves equivalently. I may look into adding more explicit tests just to avoid any regressions by clarifying the scenarios. So I believe you simply need to upgrade to resolve the issue.

[ben-manes]

Sorry, commented on the wrong issue!

[ben-manes]

Released in 3.1.3