Why doesn't Google Collections support MultiKeyMap like Apache Collections?

Question

Is the decision by Google similar to the one for SortedMultiSet (stackoverflow question) or is it because there is no use of MultiKeyMap? I am aware that an alternate for MultiKeyMap can be to use a custom Class as a key which contains the multiple keys as its class members. On the contrary, I like the concept of specifying multiple keys when calling the get of the MultiKeyMap.

Apache's version of MultiKeyMap is great but I'm severely missing Generics and therefore looked into Google Collections for a modern implementation of it. If someone has any idea why Google hasn't supported it yet or there's a better alternative for it then please respond.

Answer 1

I think generics might be the showstopper for implementation here. If you look at just the Map interface there are generic specifiers for the key type (K) and the value type (V). I don't believe it would be possible to specify it using generics easily without separating the implementations into multiple classes (one for each number of key components).

You would need a class for each:

MultiKeyMap2<K1,K2,V>
MultiKeyMap3<K1,K2,K3,V>
MultiKeyMap4<K1,K2,K3,K4,V>
MultiKeyMap5<K1,K2,K3,K4,K5,V>

The underlying implementation is basically doing what you suggest (using a custom class). However, it doesn't formally create a class for it, everything is inlined. It's really an implementation detail. But to use the Google collections a custom class to perform the same thing would operate much the same way I'm sure to implement hashCode() and equals().

Answer 2

We have a very nice implementation of a two-tiered map , which we call a "table" (K1 is the "row key" and K2 is the "column key"), and we just haven't gotten it released yet. Past two keys, though, is diminishing returns.