commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dipanjan Laha <>
Subject [collections] Issues with MultiMap generics and need of a MultiTrie
Date Sat, 22 Feb 2014 13:00:12 GMT

Recently I had the need of using a MultiMap in one of my projects. I found
that commons collection already has a MultiMap interface and an

While using the same, I found that the MultiMap interface  has methods that
are not strongly typed even though the interface supports generics. For
example if I have a MultiMap like so

MultiMap<String, User> multiMap = new MultiValueMap<String, User>();

where User is a custom  Class, then the get(key) method would return me an
Object which I would need to cast to a Collection like so

Collection<User> userCol = (Collection<User>) multiMap.get(key);

I understand that this limitation comes from that fact that the MultiMap
extends IterableMap which in turn extends Map and other interfaces. Hence
the MultiMap cannot have a get method which returns a Collection instead of
Object as that would mean extending IterableMap with the Generics set to be
<K,Collection<V>>. In that case the put method's signature would become

public Collection<V> put(K key, Collection<V> value);

which we do not want.The same problem would arise with other methods as
well, ex: containsValue method.

My proposal is why carry on the signatures of a Map and put it on MultiMap.
Where as I do agree that it is a Map after all and has very similar
implementation and functionality, it is very different at other levels. And
even though the MultiMap interface supports generics, the methods are not
strongly typed, which defeats the purpose of having generics. So why can't
we have a separate set of interfaces for MultiMap which do not extend Map.
That way we can have strongly typed methods on the MultiMap.

Please let me know your thoughts on this. I can submit a patch for these
changes based on your feedback. One more thing, I also am in need of a
MultiTrie which is currently not there. I am implementing the same by
wrapping PatriciaTrie. Now I am a bit confused here as, if I make the
MultiTrie interface on the lines of MultiMap, it would have the same
limitations. In that case I was planning to have a separate set of
interfaces for MultiTrie which does not extend any other interface. And in
case, we do change the MultiMap interface to be independent of Map, then
MultiTrie can extend MultiMap. Please let me know your thoughts on this as
well as I am implementing the same for my project right now and would like
to contribute it back to the commons collection.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message