CacheMap<K, V> is the wrong signature

[bbakerman]

The custom cache map interface has this signature CacheMap<U, V>

This might imply that it can be a cache of keys to values.

And hence you can back it with a cache like Redis (that requires values to be serializable in some way).

This is not True. It's actually a cache of promises to values aka CompleteableFuture<V>

Niavely today people have implemented a Cache<Stirng,Pojo> and then watched it blow up with class cast exceptions.

This should be fixed.

And it has a contract that is not clear.

if the dataloader "sets" a CF<V> into the cache it MUST get the exactly the same CF<V> object back on a future cached load("keyX")

The reason for this is that the batch loader causes each promise CF<V> to be "completed' given the "keyX". So if 2 calls hold different CF<V> objects, only 1 will be completed and hence the other will hang for ever.

We need to make this more clear in the code and JavaDoc

Here is an example outline the problem if the cache does not give out the same CF<V>

    CompleteableFuture<V> codePathA() {
       return dataLoader.load("keyX")
   }

and then later but before dispatch

    CompleteableFuture<V> codePathB() {
       return dataLoader.load("keyX")
   }

then later

   dataLoader.dispatch()

If ther custom cache DID NOT give back the exact same CompleteableFuture<V> object then code path B would never complete because that CompleteableFuture<V> would never be know about by the batch loading code and hence never completed. And hence it would hang