commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [collections] Dividing collections
Date Tue, 25 Mar 2008 23:10:10 GMT

--- Stephen Colebourne <scolebourne@joda.org> wrote:

> As requested, here are my views on dividing
> [collections] into smaller jars.
> 

Thanks.  :)

> 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 take this a step further, the current trunk could
move to a 4.x target, allowing the deprecations to be
removed.  Then the generics branch would
coincidentally bring about a 5.x version.  ;)

-Matt

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



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

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


Mime
View raw message