The Commons Collections team is pleased to announce the release of Commons Collections 3.1. Commons Collections provides additional interfaces and implementations based on, and inspired by, the Java Collections Framework(Collection, List, Set, Map).
- Posted by: Stephen Colebourne
- Posted on: June 29 2004 13:09 EDT
This release fixes a number of bugs in v3.0 and is fully compatible. Release v3.1 is also compatible with v2.1.1 enabling a workaround of previous compatability issues in IteratorUtils. In addition to bug fixes, this release adds various new features including:
* TreeList - A new list implementation that is faster than ArrayList in certain use cases
* MultiKeyMap - A dedicated map implementation to support combined keys mapping to a value
* ReferenceIdentityMap - An identity based map whose keys/values can be garbage collected
* Many more Serializable classes
Read the Release notes:
Download the binary distribution:
Download the source distribution:
Browse the collections website:
Please direct any feedback on issues or bugs to commons-user at jakarta.apache.org.
- Commons Collections 3.1 released by Talip Ozturk on June 29 2004 14:08 EDT
- saves reinventing the wheel by Santosh Panda on June 30 2004 03:47 EDT
MultiKeyMap ?? why not to create a [primary] key class combining keys and map it to a value, instead?
Rather than make your own little objects to combine values for the purpose of using them as map keys, this will take care of it for you. I can think of several places it would have been easier for me to just use a multikey map.
Commons Collections does already have a MultiKey class which combines keys as suggested. MultiKeyMap builds on this to provide a better API on the map class itself, avoiding the need to manually create the MultiKey objects.
multiKeyMap.put(key1, key2, value);
However, MultiKeyMap goes further than this internally. A put operation creates the MultiKey object and stores it internally as the key. A get/containsKey operation however queries the map without creating the intermediate MultiKey object. This will have significant object creation/garbage collection savings for a frequently used map.
In addition the design is based around the decorator pattern. This means that the underlying map could be the ReferenceMap (which allows its keys/values to be garbage collected in tight memory situations) or the LRUMap (which discards the least recently used when full) in addition to the regular HashedMap.
Good stuff,these Commons Collections interface/implementation saves lot of effort(reinventing the wheels) . Many a time each application development requires some sort of utility class development to support the framework,standardization of commons would lessen the effort.
WHat are you talking about? All the commons-bullshit jars are just reinventions of what's already in java.util. The few classes and tools that aren't already in there are completely useless and broken. commons could be useful, but will never be so with the completely incompetent programmers working on it as of now. You can clearly see all the complete newbie desicions in it. It's shit!
On the contrary, I found jakarta-commons consist of MANY great utilities. Of course competent programmers like Patrick will be able to write his own program to do ftp, put DB query into objects, file copy, connection pooling, calculate standard deviation, etc etc. But OO is about reuse so programers can focus on the business logics, rather than implementing something that's already written a million times. I think Patrick is completely wrong, and is quite appropriate to be called a jerk.