commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [collections] Issues with MultiMap generics and need of a MultiTrie
Date Sun, 23 Feb 2014 12:39:22 GMT
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message