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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
