From: "Henri Yandell" <[EMAIL PROTECTED]> > I've not looked at the code in question yet, but it feels like the wrong > solution. Is it not possible for the existing SequencedHashMap to be able > to wrap a FastHashMap? > > ie) SequencedHashMap.wrap(new FastHashMap()) which would override the map > used internally by sequenced hash map. Essentially, that is what the code submitted tries to do. However, it often causes difficulties, because of the multitude of views that collections provide.
> 1) java.util.Map > 2) org.apache.commons.collections.ProxyMap > 3) java.util.HashMap > 4) org.apache.commons.collections.FastHashMap [The hash denoting that it > uses hashing for its mapping internally, and not some other structure] > 5) org.apache.commons.collections.SequencedMap > > SequencedMap decorates any other map, so doesn''t matter if it's HashMap > or FastHashMap or TreeMap. Same for any other 5)s. To some degree, I agree with what you're saying. However, the main problem is with backwards compatability in [collections]. FastHashMap currently extends HashMap FastTreeMap currently extends TreeMap SequencedHashMap currently implements Map directly, and stores data in a HashMap and LinkedList Both FastHashMap and FastTreeMap are essentially the same class, and _should_ be implemented as minimal subclasses extending an abstract AbstractFastMap. FastSequencedHashMap would then extend the abstract class too and take 5 seconds to implement. Unfortunately, the original designers of these classes chose to make them extend HashMap and TreeMap even though they make no use of the implementation. This is bad for memory use (unused variables) and bad for code reuse. Presumeably, it was deemed important to have the classes as drop in replacements that would function if someone used a cast to a HashMap/TreeMap. So, we could fix the design to have an AbstractFastMap (I did this yesterday, only to realise the problem...). But this breaks backwards compatability for some users. My comments on FastSequencedHashMap were thus based on consistency with the place we are in. Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
