[collections] Dividing collections

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[collections] Dividing collections

jodastephen
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Dividing collections

Matt Benson

--- Stephen Colebourne <[hidden email]> 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:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>



      ____________________________________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Dividing collections

Torsten Curdt
In reply to this post by jodastephen
> In the end, I think that no change, and a single jar file, may still  
> be the best option.

Whoever is concerned about jar size could reduce the size at build time.
I am not so sure it's worth the hassle to split collections like  
that.... *shrug*

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Dividing collections

Henri Yandell
In reply to this post by Matt Benson
On Tue, Mar 25, 2008 at 4:10 PM, Matt Benson <[hidden email]> wrote:
>
>  --- Stephen Colebourne <[hidden email]> wrote:

>  > 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.  ;)

Or we could release 3.3, and a 4.0 right after that that is exactly
the same but without deprecations.

Tempting to do the same with Lang 2.4 -> 3.0 asap.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Dividing collections

James Carman
In reply to this post by Torsten Curdt
On Tue, Mar 25, 2008 at 7:24 PM, Torsten Curdt <[hidden email]> wrote:
> > In the end, I think that no change, and a single jar file, may still
>  > be the best option.
>
>  Whoever is concerned about jar size could reduce the size at build time.
>  I am not so sure it's worth the hassle to split collections like
>  that.... *shrug*

Aren't we also going to be removing quite a bit when we go to JDK5?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Dividing collections

Matt Benson
In reply to this post by Henri Yandell

--- Henri Yandell <[hidden email]> wrote:

> On Tue, Mar 25, 2008 at 4:10 PM, Matt Benson
> <[hidden email]> wrote:
> >
> >  --- Stephen Colebourne <[hidden email]>
> wrote:
>
> >  > 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.  ;)
>
> Or we could release 3.3, and a 4.0 right after that
> that is exactly
> the same but without deprecations.

Sounds good.
>
> Tempting to do the same with Lang 2.4 -> 3.0 asap.

Once again, why not?

Can we get a general consensus on these plans, or do
we need a formal vote?

-Matt

>
> Hen
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>



      ____________________________________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Dividing collections

Matt Benson

--- Matt Benson <[hidden email]> wrote:

>
> --- Henri Yandell <[hidden email]> wrote:
>
> > On Tue, Mar 25, 2008 at 4:10 PM, Matt Benson
> > <[hidden email]> wrote:
> > >
> > >  --- Stephen Colebourne <[hidden email]>
> > wrote:
> >
> > >  > 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.  ;)
> >
> > Or we could release 3.3, and a 4.0 right after
> that
> > that is exactly
> > the same but without deprecations.
>
> Sounds good.
> >
> > Tempting to do the same with Lang 2.4 -> 3.0 asap.
>
> Once again, why not?
>
> Can we get a general consensus on these plans, or do
> we need a formal vote?

Silence == golden == lazy consensus!

-Matt

>
> -Matt
>
> >
> > Hen
> >
> >
>
---------------------------------------------------------------------

> > To unsubscribe, e-mail:
> > [hidden email]
> > For additional commands, e-mail:
> > [hidden email]
> >
> >
>
>
>
>      
>
____________________________________________________________________________________
> 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:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>



      ____________________________________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]