Assume a potentially multi-threaded environment. I want to use a map along with (value) caching. Why would I prefer one of
collection.immutable.Map.empty[ K, SoftReference[ V ]]
new com.google.common.collect.MapMaker.softValues.makeMap[ K, V ]
over the other? The map is going to be stored in an STM ref, so immutable would be straight forward and fine. Furthermore, K is most likely going to be Long, so I could use collection.immutable.LongMap.
What would be the advantage of using google collections here? Performance and space wise?
IMO the major advantage of Google's approach is the resulting API is cleaner, i.e. the SoftReferences are inserted and null-checked for you, rather than your needing to manage them. But the guaranteed immutability and native Scala API are marks in the other column.
I'd be inclined to experiment with writing a mixin (similar to the MultiMap we already have in the standard library, which is unfortunately mutable).