DO NOT REPLY [Bug 21030] New: - PATCH MultiHashMap

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21030>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21030

PATCH MultiHashMap

           Summary: PATCH MultiHashMap
           Product: Commons
           Version: 2.1 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Collections
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: gawillia@up.com


The implementation of MultiMap and MultiHashMap currenlty offered is a very 
simple implementation and, as such, has several problems. You probably already 
know all of them, but I've listed the more obvious ones below. Since a robust 
implementation of a MultiHashMap was required for my work, I've implemented by 
own class, which I will be willing to share with you. It is very closely based 
on Sun's implementation of the HashMap class and resolves all of the issues 
listed below. Since I'm new to Jakarta, I'm not yet sure how to make 
contributions.
    1) The size() method returns the number of keys,
       not values, stored in the map. There currently
       is no way to determine how many values are
       in the map without calling values().size().
    2) The values() method is very inefficient since
       it creates an ArrayList and adds all the
       values from the map to it in a linear fashion.
       The fact that this collection is essentially
       a clone of the map is the cause of most of the
       bugs listed below.
    3) The values() method returns a collection that
       is not backed by the map, violating the 
       principles of "collection view methods"
       set forth by Sun. Making a change to the
       collection returned by values(), such as
       removing an element, will NOT modify the map.
    4) The iterator for the values collection,
       returned by values().iterator(), is not tied
       into the map in any way. Therefore, calling
       the remove() method on the iterator will NOT
       change the map.
    5) The iterator for the values collection is not
       fail-fast. Therefore, a change to the map
       during iteration will never be detected and
       may cause serious problems in a multi-threaded
       environment.
    6) Several functions that I feel should be
       included in the MultiMap inteface didn't
       exist:
           containsValue(key,item) - Removes the
               key-value mapping from the key to
               a value equal to item.
           removeValue(item) - Removes the first
               encountered value that is equal to
               item.
           removeAll(key,item) - Since the map
               should allow multiple mappings
               between equivalent key and values,
               this method should be provided so
               that all mappings between the key
               and values equivalent to item may be
               removed from the map.
           removeAll(item) - Since the map may
               store multiple mappings to equivalent
               values, this method should be
               provided so that all mappings to
               values equivalent to item may be
               removed from the map.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org