0

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?

0__
  • 66,707
  • 21
  • 171
  • 266
  • 1
    Reading this again, obviously this is not an option. "The map is going to be stored in an STM ref, so immutable would be straight forward and fine." -- it would not be fine but indeed **required**, and `MapMaker` returns a `java.util.concurrent.ConcurrentMap` which is mutable, thus not working here. I was tricked into thinking that I could have an immutable map such as `com.google.common.collect.ImmutableMap`, but `MapMaper` doesn't seem to support that. – 0__ Apr 13 '11 at 03:24

1 Answers1

0

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).

Alex Cruise
  • 7,939
  • 1
  • 27
  • 40
  • ok, but then the API is hidden anyway in my ref management at one particular spot; besides, i will have the standard API with collection.immutable.Map, and i can spare the additional dependency on another library. so i think i'll stick to scala's own class -- also see my other comment – 0__ Apr 13 '11 at 03:20