commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject [collections] Dividing collections
Date Tue, 25 Mar 2008 23:05:05 GMT
As requested, here are my views on dividing [collections] into smaller jars.

The concept comes from having a single jar file of 550K which other open 
source projects have chosen to avoid. This is perhaps understandable 
when often their own code may amount to only 150K. The question is 
whether we care about this problem, especially as more jars means more 
complications, dependencies and overhead.

The next point to consider is that the removal of the deprecated 
classes/methods from [collections] will trim the jar size quite 
noticably. Almost certainly below 500K, if not further.

Were a division to occur, I would woory about creating one jar per 
collection type. This creates simply too many jars for my liking.

If we do go for a split, perhaps we might create jars as follows:
- JDK APIs (collection/set/list/map/iterator/comparator)
- Non-JDK APIs (bag/bidimap/multimap/buffer)
- Functors (predicate/transform/closure, and associated collections)

The problem with this split is that there are methods in CollectionUtils 
that rely on the predicate interfaces. This make it very hard to 
separate the functors from the non-functors.

And after that, it becomes hard to justify just two jars.

In the end, I think that no change, and a single jar file, may still be 
the best option.

The generics branch should remove the deprecated code, and that will 
allow new growth to occur there. In fact, the generics branch could go 
further and properly separate the functor code and collections, which is 
the division that probably makes the most sense.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message