commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dipanjan Laha <>
Subject Re: [collections] Issues with MultiMap generics and need of a MultiTrie
Date Sun, 23 Feb 2014 15:06:01 GMT
Hi Thomas,

Thanks for your feedback. I created an improvement request in Jira for the
same ( ) as I thought
it could be better tracked there. Sorry for the duplication in the mail
list and Jira. I have also attached a patch in Jira where I have modified
the existing MultiMap interface and the MultiValueMap implementation and
their test cases. I agree that it would break backward compatibility and we
should go with your suggestion of deprecating the existing ones and design
fresh interfaces for the same. The patch is just a sample implementation to
demonstrate the issue and is far from being complete in terms of
documentation and test cases. I am also attaching the patch here for your

Please go through the patch and also let me know of your thoughts on how we
should proceed with the new interface and package structure. I'll be happy
to change and redirect the implementation as per your suggestion. I am new
to Apache Commons, but with some guidance I should not have issues
implementing them to start with.

As for MultiTrie, as you mentioned, we can start with it once the new
MultiMap has been finalized.


On Sun, Feb 23, 2014 at 6:09 PM, Thomas Neidhart

> On 02/22/2014 02:00 PM, Dipanjan Laha wrote:
> > Hello,
> Hi Dipanjan,
> > 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
> > implementation.
> >
> > 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.
> The MultiMap interface as it is right now is flawed, and should have
> been cleaned up prior to the 4.0 release imho (and I regretted it
> already before your post).
> As you correctly pointed out, the problem comes from the fact that it
> extends Map<K, Object> which leads to problems once generics have been
> introduced (before it did not matter that much as you had to cast
> anyway, as it is also documented in the javadoc).
> One mitigation for this was the introduction of this method to
> MultiValueMap, but it is clearly not enough:
>  public Collection<V> getCollection(Object key)
> Unfortunately, it is not easy to fix this now after collections 4.0 has
> been released. We need to keep backwards compatibility, but we could do
> the following:
>  * deprecate the existing interfaces/classes:
>    - MultiMap
>    - MultiValueMap
>  * design a new, clean interface (by not extending Map)
>  * add new package multimap with concrete implementations for different
>    types of maps (right now only hashmaps are supported)
> > 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.
> Patches are always welcome, but we first need a decision in which
> direction to go, see above.
> Regarding the MultiTrie:
> Indeed, it is the same problem, so it should go hand in hand with the
> revamp of the MultiMap interface.
> Thomas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message