You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/04/19 23:02:02 UTC
Re: [collections] Size and scope issues
Well, what is nice is to have at least SOME feedback. Often we hear of
comments made, without actually coming back here and telling us what is
wrong (or letting us explain). See inline:
From: "paulo gaspar" <"paulo gaspar">
> IMO, the collections package:
> 1) should have really commonly used collections that are missing on the
> java.util package and also
> some usefull collections building blocks for especial cases;
> 2) should NOT be a contest to implement all possible classes that have
> something to do (even
> remotedly) with collections, doesn't mater how special they might be.
#1 is not a bad aim for [collections], the trouble is everyone will define
it differently. And always remember that [collections] was originally just a
dumping ground for other peoples collections. Only now is it starting to
become complete in its own right. #2 is perception, rather than reality
IMHO.
> Examples of 1) that I like:
> - The o.a.c.collections.map.Abstract* classes, which are very useful
> building blocks;
> - o.a.c.collections.map.TypedMap, which solves a very common problem,
> before we all use JDK1.5.
Great! But I'll bet that others would say the TypedMap shouldn't exist at
all. And BTW, TypedMap uses PredicatedMap as its implementation, so they're
included too;-)
> Examples of 2) that I DISlike:
> - o.a.c.collections.map.Flat3Map??? WTF? How many humans use that?
Well I know it is in use as I've had, and fixed, a bug report against it. If
you want a small map that is very memory, performance and garbage collector
efficient this is it.
> - ALL the Unmodifiable crap, since its only advantage over the
> java.util.Collections.unmodifiable*() methods is the Unmodifiable
> marker interface, and that
> (the marker interface) is something most apps don't need, and for
> those who need, it is easy to implement;
I can understand this. The reason the classes exist is for completeness and
practicality. [collections] has interfaces that are not in the JDK, and they
need unmodifiable decorators (which aren't in the JDK). Since these 'extra
interface' unmodifiable classes got written it made sense to complete the
set - also, the map implementations often need Set and Collection
implementations anyway. Finally, there is the ability to add a little extra
functionality - Unmodifiable, and support for extracting the decorated
collection to recreate the BoundedCollection interface (try doing that with
the JDK).
> - All the o.a.c.collections.functors stuff. This is stuff for a very
> specific class of apps! Most
> useful uses of this sh*t are related with tools that have some
> visual/xml/whatever way of
> composing things. Way soes the rest of the human race have to put up
> with all of this?
History. [collections] has had functors in from the start. I would never
have added them, but they came before my time (a separate commons project
for all the functor stuff would have made more sense). However, as they were
in there we had repeated requests for default implementations, so they got
added. Would you deny user requests?
> - The o.a.c.collections.comparators. Just like the above. Even because
> comparators SHOULD
> be very performant since they tend to be called many times in on
> single action. More often
> than not, it is faster and easier to just write your own comparator
> than to compose one out
> of this stuff. And I DO things that could use a ComparatorChain and
> most of the others, but
> I would rather not have them there.
> - ...and I could go on for a while like this...
Fine, you use one, but you might use another. [collections] can't judge
based on what one user wants, but on what the balance of users want. And
again, comparators have existed in [collections] right from the start.
> IMO, what would make sence would be to have:
> 1) A core Collections package with the really common stuff + building
> blocks that ease the work
> of building custom/specific collections related stuff;
> 2) A repository of the weird packages where anyone could pick one of the
> less common bits.
>
> I don't care if there are more little collection bits, either as
> multiple collections packaged bits or
> as a packaged JAR/Docs + a repository. IF it is clearly documented what
> is the purpose of each
> bit that makes my life easier, because then I will only pick the bit
> that matters to me and its doc,
> and I will have less "noise"(*) to deal with.
The key phrase here is 'with the really common stuff'. Who defines that?
I would argue that we already do that. Remember, that code for primitive
collections was removed from [collections] - if that hadn't have been done,
[collections] could have been twice its current size. Also [events] code was
removed, as it was non-mainstream and could standalone.
Whereas, the functor code tried to find a home in numerous other places, but
in the end only [collections] was appropriate and supported by the commons
community.
BTW, some suggested additions to collections have been rejected - Trie for
example. Its always a fine balance.
Having said all that, it must be born in mind that [collections], like
[lang], operates in two ways. The first is as a jar file dependency. For
that it requires a good package layout, complete and logical set of classes
(no holes) and clear docs.
The second usage is as a cut and paste of individual classes to other
projects. This is happening with [beanutils] and [digester] where they only
ever referred to one or two collection classes and the dependency was alway
ridiculous. I have no problem with taking a collection class and embedding
it in another project, so long as the license conditions are met and the
package name is changed.
Anyway, as I said at the start, its good to have the feedback, even if you
believe that we have it totally wrong ;-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by paulo gaspar <"paulo gaspar">.
Stephen Colebourne wrote:
...
>From: "paulo gaspar" <"paulo gaspar">
>
>
>>IMO, the collections package:
>>1) should have really commonly used collections that are missing on the
>>java.util package and also
>> some usefull collections building blocks for especial cases;
>>2) should NOT be a contest to implement all possible classes that have
>>something to do (even
>> remotedly) with collections, doesn't mater how special they might be.
>>
>>
>#1 is not a bad aim for [collections], the trouble is everyone will define
>it differently. And always remember that [collections] was originally just a
>dumping ground for other peoples collections. Only now is it starting to
>become complete in its own right. #2 is perception, rather than reality
>IMHO.
>
>
Yeah, #1 is good... in principle. =;o)
...but #2 is a very strong perception, smelling like "real reality", to me.
>>Examples of 1) that I like:
>>- The o.a.c.collections.map.Abstract* classes, which are very useful
>>building blocks;
>>- o.a.c.collections.map.TypedMap, which solves a very common problem,
>>before we all use JDK1.5.
>>
>>
>Great! But I'll bet that others would say the TypedMap shouldn't exist at
>all. And BTW, TypedMap uses PredicatedMap as its implementation, so they're
>included too;-)
>
>
By need or paranoia, many people will use a "TypedMap" repeatedly if
they know they have one.
But having a Predicate interface does NOT mean you need to have all
those functors!!!
>>Examples of 2) that I DISlike:
>>- o.a.c.collections.map.Flat3Map??? WTF? How many humans use that?
>>
>>
>Well I know it is in use as I've had, and fixed, a bug report against it. If
>you want a small map that is very memory, performance and garbage collector
>efficient this is it.
>
>
I am sure all the weirdest collections were used at least once. But
should that be enough?
I already told you that I already had use for a couple of the weirdest
collections in this package,
BUT I still think they are not worth being there.
>>- ALL the Unmodifiable crap, since its only advantage over the
>> java.util.Collections.unmodifiable*() methods is the Unmodifiable
>>marker interface, and that
>> (the marker interface) is something most apps don't need, and for
>>those who need, it is easy to implement;
>>
>>
>I can understand this. The reason the classes exist is for completeness and
>practicality. [collections] has interfaces that are not in the JDK, and they
>need unmodifiable decorators (which aren't in the JDK). Since these 'extra
>interface' unmodifiable classes got written it made sense to complete the
>set - also, the map implementations often need Set and Collection
>implementations anyway. Finally, there is the ability to add a little extra
>functionality - Unmodifiable, and support for extracting the decorated
>collection to recreate the BoundedCollection interface (try doing that with
>the JDK).
>
>
But ONLY those not-in-JDK need unmodifiable decorators.
Completness is often a weak reason for too much featuritis/crap.
I am not sure that being able to extract the decorated object is a
feature. I would qualify it as a Bug
in most of the contexts where I use such thing.
- E.g.: in a IoC design, if I give to some component a UnmodifiableMap
it is usually because I
REALLY, REALLY want to avoid any possibility of that component's
code being able to change
the decorated Map.
>>- All the o.a.c.collections.functors stuff. This is stuff for a very
>>specific class of apps! Most
>> useful uses of this sh*t are related with tools that have some
>>visual/xml/whatever way of
>> composing things. Way soes the rest of the human race have to put up
>>with all of this?
>>
>>
>History. [collections] has had functors in from the start. I would never
>have added them, but they came before my time (a separate commons project
>for all the functor stuff would have made more sense). However, as they were
>in there we had repeated requests for default implementations, so they got
>added. Would you deny user requests?
>
>
I am not saying that you should deny anything. What I am saying is that
you should not impose so
much.
This means that I am not against having even the incredible Flat3Map
packaged in some way. My
problem is that I am overloaded with so much stuff if I want to use the
most "obvious" and
"common" collections.
My dream is that Collections would be split in smaller subprojects,
corresponding to smaller
packages (and docs/javadocs) to deal with. A big all-in-one package,
compatible with the current
monster-jar should still exist.
I would just like to have an easy "standard" alternative to the monster jar.
>
>
>>- The o.a.c.collections.comparators. Just like the above. Even because
>>comparators SHOULD
>>...
>>
>>
>Fine, you use one, but you might use another. [collections] can't judge
>based on what one user wants, but on what the balance of users want. And
>again, comparators have existed in [collections] right from the start.
>
>
IMO, dividing would still make everybody happy.
=:o)
>
>
>>IMO, what would make sence would be to have:
>>1) A core Collections package with the really common stuff + building
>>blocks that ease the work
>> of building custom/specific collections related stuff;
>>2) A repository of the weird packages where anyone could pick one of the
>>less common bits.
>>...
>>
>>
>The key phrase here is 'with the really common stuff'. Who defines that?
>
>
Dividing with care, by "theme", can also solve this.
>...
>BTW, some suggested additions to collections have been rejected - Trie for
>example. Its always a fine balance.
>
>
I was not implying this is easy. There is a reason why I became so quiet
here during the last couple
of years...
=;o)
>Having said all that, it must be born in mind that [collections], like
>[lang], operates in two ways. The first is as a jar file dependency. For
>that it requires a good package layout, complete and logical set of classes
>(no holes) and clear docs.
>
>
This (no holes) thing is also something that must be taken with a grain
of salt...
>The second usage is as a cut and paste of individual classes to other
>projects. This is happening with [beanutils] and [digester] where they only
>ever referred to one or two collection classes and the dependency was alway
>ridiculous. I have no problem with taking a collection class and embedding
>it in another project, so long as the license conditions are met and the
>package name is changed.
>
>
The license warrants that possibility, of course.
>Anyway, as I said at the start, its good to have the feedback, even if you
>believe that we have it totally wrong ;-)
>
>
I never meant that (the "tottaly wrong" bit)..
And I see improvement since last time I looked at collections with some
attention (when the
primitives stuff was still on the mix and so), which was a really scary
experience!
Now it was not so bad!
=;o)
Seriously, not only do I see the primites out, but I also have the idea
that everything is better
placed and fits better together. Last time I was just going to quit
using Collections, now I am taking
the time to bother you into providing alternative packaging.
=:oD
>Stephen
>
>
Paulo Gaspar
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Herve Quiroz <he...@esil.univ-mrs.fr>.
On Thu, Apr 22, 2004 at 08:17:51PM +0100, Stephen Colebourne wrote:
> Its always good to see the opposing points of view ;-) Thanks for all
> feedback.
>
> Following this discussion I did a search around the web to try and find
> references to collections causing a problem by its size. I didn't really
> find any, but that doesn't prove anything.
>
> The appserver point is part of what jakarta is about, and dropping in a
> library should not result in concerns over size. On the other hand, projects
> like beanutils and digester which used one collection each are quite correct
> to terminate the dependency and cut and paste.
>
> One point I should make is that commons frequently gets requests to release
> everything as one jar. Finding the right component size is always tricky. I
> would argue collections is about right. The biggest query is really over the
> functors, but thats a long story - see the mail archives for the pain that
> they were.
>
> I would also argue against having a collections-all and collection-part
> release strategy. Its all too easy to mess up and to have an old
> collections-all blocking a newer collections-part.
>
> Finally, half the problem with size in collections comes from the Sun
> interfaces. Map especially requires an awful lot of classes to implement,
> and that takes up space ;-)
>
> I will go and have a look to see if anything can be done to trim space. Who
> knows, there may be something simple!
Stephen,
Maybe the proxy stuff I suggested for [events] could work for most of
the decorators we have in [collections]. And as I said for [events], in
many cases, one decorator fits many collections, so this could help to
reduce the size of [collections].
Anyway, there might be performance issues with proxies... but I don't
know much on this subject actually.
Herve
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 3 May 2004, at 16:12, Dain Sundstrom wrote:
<snip>
> Instead of just bitching, I'll suggest a possible solution. Pick
> someone in your project who understands the issues, has shown an
> interest in these problems, and give them the authority to make
> decisions. I know it is not very "Apache", but I believe it will
> work.
i know that i've said it before but i'm not really convinced that this
is so much an authority issue as an awareness/motivation issue. if
there are good and well-known reasons why small footprint distributions
are required, then i'd say that it's unlikely anyone would veto the
creation of extra build targets for more modular distributions as well
as the current monolithic ones.
the main problem is that there's been a lot of pressure from users in
the other direction - bigger distributions, fewer jars. we've had quite
a fair number of requests for comprehensive distributions containing
everything in the jakarta commons but (until recently) very few people
have come and made compelling arguments for the need for more compact
and focussed distributions.
we could probably satisfy both those who want comprehensive libraries
and those who need more compact ones by providing a monolithic jar and
a set of modular jars within the binary distribution. wouldn't this
satisfy both needs?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] KeySetMap?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This would be a very unusual map implementation (I can't figure out what
your keys might be, and thus why you wouldn't use a Set or Bag).
What you describe is a FixedSizeMap with the exception that keys can be
added via the keySet(). This is a violaton of keySet() (which states that
add is not supported), but an acceptable violation.
An alternative way to view this is that the set of keys that controls the
map is not the keySet(). ie. provide another method, controlKeySet(), to
access that set.
One more alternative - create a small holder class that holds your key and
value (like Map Entry), but where the equals and hashCode is derived only
from the key. Then just use a Set (instead of a map) where each entry is
this new holder class.
Stephen
From: "Michael Heuer" <he...@acm.org>
> On Tue, 4 May 2004, Stephen Colebourne wrote:
> > This sounds more like a map that validates whether its keys are in a
> > predetermined Set. That way, the map would operate as normal, size is
size
> > of mappings, cannot add to keySet but can remove etc.
>
> Right, but that is only part of it. I would like to support
>
> Set keys = ...{ "foo", "bar" };
> Map map = new KeySetMap(keys);
>
> map.put("foo", 1);
> assert(map.containsKey("foo") == true);
> assert(map.get("foo") == 1);
>
> keys.remove("foo");
> assert(map.containsKey("foo") == false);
> assert(map.get("foo") == null);
>
> keys.add("baz");
> assert(map.containsKey("baz") == true);
> assert(map.get("baz") == null);
>
> but not any of
>
> map.remove("foo");
> map.keySet().remove("foo");
> map.keySet().iterator() ... remove();
> map.put("not a key in keys", 0);
>
> I thought it may be possible to implement this without breaking the Map
> interface contract (by throwing UnsupportedOperationException where
> appropriate), but I'm not so sure.
>
> michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] KeySetMap?
Posted by Michael Heuer <he...@acm.org>.
On Tue, 4 May 2004, Stephen Colebourne wrote:
> This sounds more like a map that validates whether its keys are in a
> predetermined Set. That way, the map would operate as normal, size is size
> of mappings, cannot add to keySet but can remove etc.
Right, but that is only part of it. I would like to support
Set keys = ...{ "foo", "bar" };
Map map = new KeySetMap(keys);
map.put("foo", 1);
assert(map.containsKey("foo") == true);
assert(map.get("foo") == 1);
keys.remove("foo");
assert(map.containsKey("foo") == false);
assert(map.get("foo") == null);
keys.add("baz");
assert(map.containsKey("baz") == true);
assert(map.get("baz") == null);
but not any of
map.remove("foo");
map.keySet().remove("foo");
map.keySet().iterator() ... remove();
map.put("not a key in keys", 0);
I thought it may be possible to implement this without breaking the Map
interface contract (by throwing UnsupportedOperationException where
appropriate), but I'm not so sure.
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] KeySetMap?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This sounds more like a map that validates whether its keys are in a
predetermined Set. That way, the map would operate as normal, size is size
of mappings, cannot add to keySet but can remove etc.
The main idea is to separate the validation Set from the actual keySet. This
is now really easy to achieve as I checked in the
AbstractInputCheckedMapDecorator today, which allows validation to be easily
performed (see checkPutKey). Or use AbstractHashedMap if you don't want to
decorate (see addMapping).
Stephen
----- Original Message -----
From: "Michael Heuer" <he...@acm.org>
> I need an implementation of Map that uses a predefined set of keys as its
> keySet. Changes made to the set of keys should be reflected in the map's
> keySet but not the other way around, e.g. map.keySet() should be
> unmodifiable.
>
> I've written something using a wrapped map but I'm having trouble
> specifying all of the desired behavior. For instance, if the size of
> the keySet is > 0 but no mappings exist, what is the size of the map?
> Would the entrySet view contain entries containing each key mapped to
> null? What should map.remove(key) do? etc.
>
> Any comments are appreciated.
>
> michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[collections] KeySetMap?
Posted by Michael Heuer <he...@acm.org>.
Hello,
I need an implementation of Map that uses a predefined set of keys as its
keySet. Changes made to the set of keys should be reflected in the map's
keySet but not the other way around, e.g. map.keySet() should be
unmodifiable.
I've written something using a wrapped map but I'm having trouble
specifying all of the desired behavior. For instance, if the size of
the keySet is > 0 but no mappings exist, what is the size of the map?
Would the entrySet view contain entries containing each key mapped to
null? What should map.remove(key) do? etc.
Any comments are appreciated.
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Stephen Colebourne <sc...@btopenworld.com>.
OK, I have added extra targets to the ant script to build alternate jars.
bag - 25k
bidimap - 45k
buffer - 22k
comparators - 16k
functors - 59k
main - 312k (list+set+map+collection+keyvalue)
deprecated - 91k
This compares to a current jar size of:
all - 536k
or with deprecated classes excluded:
all-minus-deprecated - 450k
Interesting fact - the new Apache licence takes up just over 4k, or 25% of
the comparators jar. You gotta love that new licence. Also note that a
single map class can easily be 15k (jarred) - its a very difficult interface
to implement.
So......the question is whether creating all these jars is justified to go
from 450k to 312k, which I would argue are the genuine comparable sizes.
There has been a call for 'picking and choosing' collections, but basically
that just isn't realistic. Not only is there no agreement on what is good
and what is bad, but it would be highly prone to error trying to ensure that
the correct files are included.
Finally, [collections] is not just about providing canned implementations
for people to use, but also about providing usful abstract classes (and a
test framework) that make the job of actually implementing collections (and
especially maps) easier.
Stephen
> I will try and get a breakdown of sizes within the jar at some point to
try
> and understand this further. I evaluated the code today, and found that
> picking and choosing classes for a smaller jar would prove difficult -
there
> is quite high reuse within the package, and lots of backwards
compatability
> to consider.
>
> Finally, I would say that if you have such a small target size, then I
> suspect that you will always take the pick and choose (repackage) option
> with collections. So my question would go back to your as, if there was a
> collection/list/set/map only jar (no
bag/bidimap/buffer/comparator/functor),
> would you use it? Bear in mind that in order to produce more jars, the
> overall size will actually have to go up.
>
> Stephen
>
>
> ----- Original Message -----
> From: "Dain Sundstrom" <da...@coredevelopers.net>
> > I can say that it is not politics for the Geronimo project. Our goal
> > is to keep our stand alone kernel small (under 4mb) and a full Geronimo
> > server under 16mb (I'm shooting for under 8). Small size is important
> > as it directly effects the places where people will be using the
> > server. There is a demand for J2EE servers in small hardware. Anyway,
> > just taking a quick look at ibiblio this is the history of
> > commons-collections
> >
> > commons-collections-1.0.jar 84k
> > commons-collections-2.0.jar 88k
> > commons-collections-2.1.jar 161k
> > commons-collections-3.0.jar 506k
> > commons-collections-SNAPSHOT.jar 842k
> >
> > I find it hard to believe that there are almost 1mb of truly common
> > collections. Either way, the writing is on the wall, the package is
> > growing and growing quickly. Not only that, since this library is
> > widely used in commons, all of those projects are growing at a rapid
> > rate.
> >
> > Building small tight code is not easy, especially as Craig put it the
> > other day "perceptions of 'really common' versus 'rarely used' seem to
> > be awfully personal". The alternative is you end up with huge
> > highly-coupled libraries and no one wants to use them anymore.
> >
> > Instead of just bitching, I'll suggest a possible solution. Pick
> > someone in your project who understands the issues, has shown an
> > interest in these problems, and give them the authority to make
> > decisions. I know it is not very "Apache", but I believe it will work.
> >
> > -dain
> >
> > /*************************
> > * Dain Sundstrom
> > * Partner
> > * Core Developers Network
> > *************************/
> >
> > On May 3, 2004, at 2:11 AM, robert burrell donkin wrote:
> >
> > > i definitely agree that one jar is the best solution for many users.
> > > for those users for whom jar size is a big issue, then i'd say for
> > > that for many use cases rolling a custom version (possibly repackaged)
> > > is the best approach. (i have heard that this is how BEA re-uses the
> > > commons logging stuff.)
> > >
> > > but we've been hearing that for some users - many of them influential
> > > open source developers - this approach is unsatisfactory. one of the
> > > main aims for jakarta commons was to facilitate re-use of library code
> > > between open source projects. there are a few of ASF projects who are
> > > refusing to use any jakarta commons components on principle now for
> > > this reason. (they want small, tight libraries.) i suspect that this
> > > is partly political but there is a kernel of truth in the criticisms.
> > > it's best to think about this kind of issue early before a momentum
> > > develops.
> > >
> > > certainly, i'm keen to see digester 2 (if and when it comes along)
> > > factored into a small core with minimal dependencies together with
> > > optional extensions. the binary distribution would contain both a
> > > single complete jar and a set of multiple jars. i hope that this
> > > should be able to satisfy most users and since this is just a build
> > > issue, i suspect that the maintenance would be minimal.
> > >
> > > - robert
> > >
> > > On 3 May 2004, at 00:41, Stephen Colebourne wrote:
> > >
> > >> So what problem are we solving? Adding extra jar files alongside the
> > >> complete built one creates classpath problems for users, an old
> > >> version of
> > >> the 'all' jar overriding a later version of the 'part' jar or vice
> > >> versa.
> > >> General chaos and confusion.
> > >>
> > >> People so have the ability to build their own jar files with just the
> > >> classes they need.
> > >>
> > >> Oh, and I'd also suggest that more jar files does involve more work
> > >> (maintaining and releasing), and there's a distinct lack of active
> > >> committers on collections as it is ;-)
> > >>
> > >> Stephen
> > >>
> > >>> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
> > >>>> A neat ideal, but perceptions of "really common" versus "rarely
> > >>>> used"
> > >>>> seem to be awfully personal. Kinda reminds me of earlier
> > >>>> commons-dev
> > >>>> discussions trying to create a "commons core" JAR that included all
> > >>>> of
> > >>>> the "really common" commons JARs, and none of the others. Needless
> > >>>> to
> > >>>> say, there was no consensus on what the contents should be :-).
> > >>
> > >> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > >>> i wonder whether it might be possible to separate out a core jar
> > >>> containing just the basic interfaces and then split the
> > >>> implementations
> > >>> into several themed jars. i still think that this should be in
> > >>> addition
> > >>> to releasing a single jar containing everything, though.
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Thanks for responding, its useful to try to understand WHY there are isues
with collections and other commons packages.
I'll correct one point of fact below - the commons-collections-SNAPSHOT is
earlier in time than v3.0, and represents a state before the primitive
collections got kicked out (precisely because I worried about size and scope
at that point). The latest jar size is 548k. This affects your next comment.
Also, FYI 2.1 to 3.0 represents a very large jump in time, over 18 months
IIRC.
I will try and get a breakdown of sizes within the jar at some point to try
and understand this further. I evaluated the code today, and found that
picking and choosing classes for a smaller jar would prove difficult - there
is quite high reuse within the package, and lots of backwards compatability
to consider.
Finally, I would say that if you have such a small target size, then I
suspect that you will always take the pick and choose (repackage) option
with collections. So my question would go back to your as, if there was a
collection/list/set/map only jar (no bag/bidimap/buffer/comparator/functor),
would you use it? Bear in mind that in order to produce more jars, the
overall size will actually have to go up.
Stephen
----- Original Message -----
From: "Dain Sundstrom" <da...@coredevelopers.net>
> I can say that it is not politics for the Geronimo project. Our goal
> is to keep our stand alone kernel small (under 4mb) and a full Geronimo
> server under 16mb (I'm shooting for under 8). Small size is important
> as it directly effects the places where people will be using the
> server. There is a demand for J2EE servers in small hardware. Anyway,
> just taking a quick look at ibiblio this is the history of
> commons-collections
>
> commons-collections-1.0.jar 84k
> commons-collections-2.0.jar 88k
> commons-collections-2.1.jar 161k
> commons-collections-3.0.jar 506k
> commons-collections-SNAPSHOT.jar 842k
>
> I find it hard to believe that there are almost 1mb of truly common
> collections. Either way, the writing is on the wall, the package is
> growing and growing quickly. Not only that, since this library is
> widely used in commons, all of those projects are growing at a rapid
> rate.
>
> Building small tight code is not easy, especially as Craig put it the
> other day "perceptions of 'really common' versus 'rarely used' seem to
> be awfully personal". The alternative is you end up with huge
> highly-coupled libraries and no one wants to use them anymore.
>
> Instead of just bitching, I'll suggest a possible solution. Pick
> someone in your project who understands the issues, has shown an
> interest in these problems, and give them the authority to make
> decisions. I know it is not very "Apache", but I believe it will work.
>
> -dain
>
> /*************************
> * Dain Sundstrom
> * Partner
> * Core Developers Network
> *************************/
>
> On May 3, 2004, at 2:11 AM, robert burrell donkin wrote:
>
> > i definitely agree that one jar is the best solution for many users.
> > for those users for whom jar size is a big issue, then i'd say for
> > that for many use cases rolling a custom version (possibly repackaged)
> > is the best approach. (i have heard that this is how BEA re-uses the
> > commons logging stuff.)
> >
> > but we've been hearing that for some users - many of them influential
> > open source developers - this approach is unsatisfactory. one of the
> > main aims for jakarta commons was to facilitate re-use of library code
> > between open source projects. there are a few of ASF projects who are
> > refusing to use any jakarta commons components on principle now for
> > this reason. (they want small, tight libraries.) i suspect that this
> > is partly political but there is a kernel of truth in the criticisms.
> > it's best to think about this kind of issue early before a momentum
> > develops.
> >
> > certainly, i'm keen to see digester 2 (if and when it comes along)
> > factored into a small core with minimal dependencies together with
> > optional extensions. the binary distribution would contain both a
> > single complete jar and a set of multiple jars. i hope that this
> > should be able to satisfy most users and since this is just a build
> > issue, i suspect that the maintenance would be minimal.
> >
> > - robert
> >
> > On 3 May 2004, at 00:41, Stephen Colebourne wrote:
> >
> >> So what problem are we solving? Adding extra jar files alongside the
> >> complete built one creates classpath problems for users, an old
> >> version of
> >> the 'all' jar overriding a later version of the 'part' jar or vice
> >> versa.
> >> General chaos and confusion.
> >>
> >> People so have the ability to build their own jar files with just the
> >> classes they need.
> >>
> >> Oh, and I'd also suggest that more jar files does involve more work
> >> (maintaining and releasing), and there's a distinct lack of active
> >> committers on collections as it is ;-)
> >>
> >> Stephen
> >>
> >>> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
> >>>> A neat ideal, but perceptions of "really common" versus "rarely
> >>>> used"
> >>>> seem to be awfully personal. Kinda reminds me of earlier
> >>>> commons-dev
> >>>> discussions trying to create a "commons core" JAR that included all
> >>>> of
> >>>> the "really common" commons JARs, and none of the others. Needless
> >>>> to
> >>>> say, there was no consensus on what the contents should be :-).
> >>
> >> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> >>> i wonder whether it might be possible to separate out a core jar
> >>> containing just the basic interfaces and then split the
> >>> implementations
> >>> into several themed jars. i still think that this should be in
> >>> addition
> >>> to releasing a single jar containing everything, though.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Dain Sundstrom <da...@coredevelopers.net>.
I can say that it is not politics for the Geronimo project. Our goal
is to keep our stand alone kernel small (under 4mb) and a full Geronimo
server under 16mb (I'm shooting for under 8). Small size is important
as it directly effects the places where people will be using the
server. There is a demand for J2EE servers in small hardware. Anyway,
just taking a quick look at ibiblio this is the history of
commons-collections
commons-collections-1.0.jar 84k
commons-collections-2.0.jar 88k
commons-collections-2.1.jar 161k
commons-collections-3.0.jar 506k
commons-collections-SNAPSHOT.jar 842k
I find it hard to believe that there are almost 1mb of truly common
collections. Either way, the writing is on the wall, the package is
growing and growing quickly. Not only that, since this library is
widely used in commons, all of those projects are growing at a rapid
rate.
Building small tight code is not easy, especially as Craig put it the
other day "perceptions of 'really common' versus 'rarely used' seem to
be awfully personal". The alternative is you end up with huge
highly-coupled libraries and no one wants to use them anymore.
Instead of just bitching, I'll suggest a possible solution. Pick
someone in your project who understands the issues, has shown an
interest in these problems, and give them the authority to make
decisions. I know it is not very "Apache", but I believe it will work.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
On May 3, 2004, at 2:11 AM, robert burrell donkin wrote:
> i definitely agree that one jar is the best solution for many users.
> for those users for whom jar size is a big issue, then i'd say for
> that for many use cases rolling a custom version (possibly repackaged)
> is the best approach. (i have heard that this is how BEA re-uses the
> commons logging stuff.)
>
> but we've been hearing that for some users - many of them influential
> open source developers - this approach is unsatisfactory. one of the
> main aims for jakarta commons was to facilitate re-use of library code
> between open source projects. there are a few of ASF projects who are
> refusing to use any jakarta commons components on principle now for
> this reason. (they want small, tight libraries.) i suspect that this
> is partly political but there is a kernel of truth in the criticisms.
> it's best to think about this kind of issue early before a momentum
> develops.
>
> certainly, i'm keen to see digester 2 (if and when it comes along)
> factored into a small core with minimal dependencies together with
> optional extensions. the binary distribution would contain both a
> single complete jar and a set of multiple jars. i hope that this
> should be able to satisfy most users and since this is just a build
> issue, i suspect that the maintenance would be minimal.
>
> - robert
>
> On 3 May 2004, at 00:41, Stephen Colebourne wrote:
>
>> So what problem are we solving? Adding extra jar files alongside the
>> complete built one creates classpath problems for users, an old
>> version of
>> the 'all' jar overriding a later version of the 'part' jar or vice
>> versa.
>> General chaos and confusion.
>>
>> People so have the ability to build their own jar files with just the
>> classes they need.
>>
>> Oh, and I'd also suggest that more jar files does involve more work
>> (maintaining and releasing), and there's a distinct lack of active
>> committers on collections as it is ;-)
>>
>> Stephen
>>
>>> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
>>>> A neat ideal, but perceptions of "really common" versus "rarely
>>>> used"
>>>> seem to be awfully personal. Kinda reminds me of earlier
>>>> commons-dev
>>>> discussions trying to create a "commons core" JAR that included all
>>>> of
>>>> the "really common" commons JARs, and none of the others. Needless
>>>> to
>>>> say, there was no consensus on what the contents should be :-).
>>
>> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
>>> i wonder whether it might be possible to separate out a core jar
>>> containing just the basic interfaces and then split the
>>> implementations
>>> into several themed jars. i still think that this should be in
>>> addition
>>> to releasing a single jar containing everything, though.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Stephen Colebourne <sc...@btopenworld.com>.
OK, there are various cross package dependencies that have to be removed to
make life simpler for separate jars.
1) ObjectGraphIterator depends on NOPTransformer - I've reworked it to
remove the dependency
2) LazyMap depends on FactoryTransformer - This can only be reworked by
copying FactoryTransformer as an inner class of LazyMap. This does seem a
little crazy.
3) UniqueFilterIterator depends on UniquePredicate - Requires the inner
class to be copied.
4) Typed* collections depend on InstanceofPredicate - I am planning on
adding a new AbstractInputCheckingMapDecorator class which would help the
map cases. It would allow the validation to occur without needing to create
a predicate. Adding the new class also reduces overall jar size.
Thus, we could then create jars for
- Bag
- BidiMap
- Buffer
- Comparator
- Functor
- Core (main/collection/set/list/map)
Still not sure I really want to do this though :-(
Stephen
----- Original Message -----
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> i definitely agree that one jar is the best solution for many users.
> for those users for whom jar size is a big issue, then i'd say for that
> for many use cases rolling a custom version (possibly repackaged) is
> the best approach. (i have heard that this is how BEA re-uses the
> commons logging stuff.)
>
> but we've been hearing that for some users - many of them influential
> open source developers - this approach is unsatisfactory. one of the
> main aims for jakarta commons was to facilitate re-use of library code
> between open source projects. there are a few of ASF projects who are
> refusing to use any jakarta commons components on principle now for
> this reason. (they want small, tight libraries.) i suspect that this is
> partly political but there is a kernel of truth in the criticisms. it's
> best to think about this kind of issue early before a momentum
> develops.
>
> certainly, i'm keen to see digester 2 (if and when it comes along)
> factored into a small core with minimal dependencies together with
> optional extensions. the binary distribution would contain both a
> single complete jar and a set of multiple jars. i hope that this should
> be able to satisfy most users and since this is just a build issue, i
> suspect that the maintenance would be minimal.
>
> - robert
>
> On 3 May 2004, at 00:41, Stephen Colebourne wrote:
>
> > So what problem are we solving? Adding extra jar files alongside the
> > complete built one creates classpath problems for users, an old
> > version of
> > the 'all' jar overriding a later version of the 'part' jar or vice
> > versa.
> > General chaos and confusion.
> >
> > People so have the ability to build their own jar files with just the
> > classes they need.
> >
> > Oh, and I'd also suggest that more jar files does involve more work
> > (maintaining and releasing), and there's a distinct lack of active
> > committers on collections as it is ;-)
> >
> > Stephen
> >
> >> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
> >>> A neat ideal, but perceptions of "really common" versus "rarely used"
> >>> seem to be awfully personal. Kinda reminds me of earlier commons-dev
> >>> discussions trying to create a "commons core" JAR that included all
> >>> of
> >>> the "really common" commons JARs, and none of the others. Needless
> >>> to
> >>> say, there was no consensus on what the contents should be :-).
> >
> > From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> >> i wonder whether it might be possible to separate out a core jar
> >> containing just the basic interfaces and then split the
> >> implementations
> >> into several themed jars. i still think that this should be in
> >> addition
> >> to releasing a single jar containing everything, though.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 3 May 2004, at 10:00, Stephen Colebourne wrote:
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
>> between open source projects. there are a few of ASF projects who are
>> refusing to use any jakarta commons components on principle now for
>> this reason. (they want small, tight libraries.)
> Can you specify which? This has been mentioned before without clarity.
geronimo in particular
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> between open source projects. there are a few of ASF projects who are
> refusing to use any jakarta commons components on principle now for
> this reason. (they want small, tight libraries.)
Can you specify which? This has been mentioned before without clarity.
Stephen
> On 3 May 2004, at 00:41, Stephen Colebourne wrote:
>
> > So what problem are we solving? Adding extra jar files alongside the
> > complete built one creates classpath problems for users, an old
> > version of
> > the 'all' jar overriding a later version of the 'part' jar or vice
> > versa.
> > General chaos and confusion.
> >
> > People so have the ability to build their own jar files with just the
> > classes they need.
> >
> > Oh, and I'd also suggest that more jar files does involve more work
> > (maintaining and releasing), and there's a distinct lack of active
> > committers on collections as it is ;-)
> >
> > Stephen
> >
> >> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
> >>> A neat ideal, but perceptions of "really common" versus "rarely used"
> >>> seem to be awfully personal. Kinda reminds me of earlier commons-dev
> >>> discussions trying to create a "commons core" JAR that included all
> >>> of
> >>> the "really common" commons JARs, and none of the others. Needless
> >>> to
> >>> say, there was no consensus on what the contents should be :-).
> >
> > From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> >> i wonder whether it might be possible to separate out a core jar
> >> containing just the basic interfaces and then split the
> >> implementations
> >> into several themed jars. i still think that this should be in
> >> addition
> >> to releasing a single jar containing everything, though.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i definitely agree that one jar is the best solution for many users.
for those users for whom jar size is a big issue, then i'd say for that
for many use cases rolling a custom version (possibly repackaged) is
the best approach. (i have heard that this is how BEA re-uses the
commons logging stuff.)
but we've been hearing that for some users - many of them influential
open source developers - this approach is unsatisfactory. one of the
main aims for jakarta commons was to facilitate re-use of library code
between open source projects. there are a few of ASF projects who are
refusing to use any jakarta commons components on principle now for
this reason. (they want small, tight libraries.) i suspect that this is
partly political but there is a kernel of truth in the criticisms. it's
best to think about this kind of issue early before a momentum
develops.
certainly, i'm keen to see digester 2 (if and when it comes along)
factored into a small core with minimal dependencies together with
optional extensions. the binary distribution would contain both a
single complete jar and a set of multiple jars. i hope that this should
be able to satisfy most users and since this is just a build issue, i
suspect that the maintenance would be minimal.
- robert
On 3 May 2004, at 00:41, Stephen Colebourne wrote:
> So what problem are we solving? Adding extra jar files alongside the
> complete built one creates classpath problems for users, an old
> version of
> the 'all' jar overriding a later version of the 'part' jar or vice
> versa.
> General chaos and confusion.
>
> People so have the ability to build their own jar files with just the
> classes they need.
>
> Oh, and I'd also suggest that more jar files does involve more work
> (maintaining and releasing), and there's a distinct lack of active
> committers on collections as it is ;-)
>
> Stephen
>
>> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
>>> A neat ideal, but perceptions of "really common" versus "rarely used"
>>> seem to be awfully personal. Kinda reminds me of earlier commons-dev
>>> discussions trying to create a "commons core" JAR that included all
>>> of
>>> the "really common" commons JARs, and none of the others. Needless
>>> to
>>> say, there was no consensus on what the contents should be :-).
>
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
>> i wonder whether it might be possible to separate out a core jar
>> containing just the basic interfaces and then split the
>> implementations
>> into several themed jars. i still think that this should be in
>> addition
>> to releasing a single jar containing everything, though.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Stephen Colebourne <sc...@btopenworld.com>.
So what problem are we solving? Adding extra jar files alongside the
complete built one creates classpath problems for users, an old version of
the 'all' jar overriding a later version of the 'part' jar or vice versa.
General chaos and confusion.
People so have the ability to build their own jar files with just the
classes they need.
Oh, and I'd also suggest that more jar files does involve more work
(maintaining and releasing), and there's a distinct lack of active
committers on collections as it is ;-)
Stephen
> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
> > A neat ideal, but perceptions of "really common" versus "rarely used"
> > seem to be awfully personal. Kinda reminds me of earlier commons-dev
> > discussions trying to create a "commons core" JAR that included all of
> > the "really common" commons JARs, and none of the others. Needless to
> > say, there was no consensus on what the contents should be :-).
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> i wonder whether it might be possible to separate out a core jar
> containing just the basic interfaces and then split the implementations
> into several themed jars. i still think that this should be in addition
> to releasing a single jar containing everything, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
> Dain Sundstrom wrote:
>
>> On Apr 22, 2004, at 2:40 PM, Michael Heuer wrote:
>>
>>> Perhaps some of the classes in [collections] could be presented as a
>>> JSR
>>> for inclusion in the JDK at some later date. That might cut the
>>> size of
>>> the jar some. :)
>>
>>
>> All kidding aside, I like this idea. How about starting by splitting
>> collections into, really common collections, and the rarely used
>> collections.
>
>
> A neat ideal, but perceptions of "really common" versus "rarely used"
> seem to be awfully personal. Kinda reminds me of earlier commons-dev
> discussions trying to create a "commons core" JAR that included all of
> the "really common" commons JARs, and none of the others. Needless to
> say, there was no consensus on what the contents should be :-).
i wonder whether it might be possible to separate out a core jar
containing just the basic interfaces and then split the implementations
into several themed jars. i still think that this should be in addition
to releasing a single jar containing everything, though.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Dain Sundstrom wrote:
> On Apr 22, 2004, at 2:40 PM, Michael Heuer wrote:
>
>> Perhaps some of the classes in [collections] could be presented as a JSR
>> for inclusion in the JDK at some later date. That might cut the size of
>> the jar some. :)
>
>
> All kidding aside, I like this idea. How about starting by splitting
> collections into, really common collections, and the rarely used
> collections.
A neat ideal, but perceptions of "really common" versus "rarely used"
seem to be awfully personal. Kinda reminds me of earlier commons-dev
discussions trying to create a "commons core" JAR that included all of
the "really common" commons JARs, and none of the others. Needless to
say, there was no consensus on what the contents should be :-).
>
> -dain
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] Size and scope issues
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Perhaps some of the classes in [collections] could be presented as a
> > JSR for inclusion in the JDK at some later date.
> All kidding aside, I like this idea.
First up on my list would be the ReferenceMap. Useful and flexible.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Apr 22, 2004, at 2:40 PM, Michael Heuer wrote:
> Perhaps some of the classes in [collections] could be presented as a
> JSR
> for inclusion in the JDK at some later date. That might cut the size
> of
> the jar some. :)
All kidding aside, I like this idea. How about starting by splitting
collections into, really common collections, and the rarely used
collections.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Michael Heuer <he...@acm.org>.
On Thu, 22 Apr 2004, Stephen Colebourne wrote:
> Its always good to see the opposing points of view ;-) Thanks for all
> feedback.
>
> Following this discussion I did a search around the web to try and find
> references to collections causing a problem by its size. I didn't really
> find any, but that doesn't prove anything.
>
> The appserver point is part of what jakarta is about, and dropping in a
> library should not result in concerns over size. On the other hand, projects
> like beanutils and digester which used one collection each are quite correct
> to terminate the dependency and cut and paste.
>
> One point I should make is that commons frequently gets requests to release
> everything as one jar. Finding the right component size is always tricky. I
> would argue collections is about right. The biggest query is really over the
> functors, but thats a long story - see the mail archives for the pain that
> they were.
>
> I would also argue against having a collections-all and collection-part
> release strategy. Its all too easy to mess up and to have an old
> collections-all blocking a newer collections-part.
I agree.
> Finally, half the problem with size in collections comes from the Sun
> interfaces. Map especially requires an awful lot of classes to implement,
> and that takes up space ;-)
>
> I will go and have a look to see if anything can be done to trim space. Who
> knows, there may be something simple!
Perhaps some of the classes in [collections] could be presented as a JSR
for inclusion in the JDK at some later date. That might cut the size of
the jar some. :)
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Its always good to see the opposing points of view ;-) Thanks for all
feedback.
Following this discussion I did a search around the web to try and find
references to collections causing a problem by its size. I didn't really
find any, but that doesn't prove anything.
The appserver point is part of what jakarta is about, and dropping in a
library should not result in concerns over size. On the other hand, projects
like beanutils and digester which used one collection each are quite correct
to terminate the dependency and cut and paste.
One point I should make is that commons frequently gets requests to release
everything as one jar. Finding the right component size is always tricky. I
would argue collections is about right. The biggest query is really over the
functors, but thats a long story - see the mail archives for the pain that
they were.
I would also argue against having a collections-all and collection-part
release strategy. Its all too easy to mess up and to have an old
collections-all blocking a newer collections-part.
Finally, half the problem with size in collections comes from the Sun
interfaces. Map especially requires an awful lot of classes to implement,
and that takes up space ;-)
I will go and have a look to see if anything can be done to trim space. Who
knows, there may be something simple!
Stephen
----- Original Message -----
From: "Simon Kitching" <si...@ecnetwork.co.nz>
> On Thu, 2004-04-22 at 08:48, paulo gaspar wrote:
> > Stephen Colebourne wrote:
> > >>IMO, the collections package:
> > >>1) should have really commonly used collections that are missing on
the
> > >>java.util package and also
> > >> some usefull collections building blocks for especial cases;
> > >>2) should NOT be a contest to implement all possible classes that have
> > >>something to do (even
> > >> remotedly) with collections, doesn't mater how special they might
be.
>
> I think that collections is fine as it is.
>
> Jakarta's whole goal is to provide "server" components for java. If
> these happen to also be useful for applets, then that is great. However
> I believe that those people who want to use jakarta components in
> environments that are constrained by network bandwidth or RAM or disk
> space are responsible for themselves repackaging the bits they want.
>
> Remember, if anyone wants to write an applet and use some of the great
> collection classes in commons-collections, there is nothing to prevent
> them from selecting the classes they want and creating a custom jar
> file.
>
> >
> > ..but #2 is a very strong perception, smelling like "real reality", to
me.
>
> And it smells differently to me. I like having a single project that
> collects a number of collections together. In fact, I would probably
> have preferred to have the primitive collections in the same project and
> jar.
>
> Having "unused" classes present in a jar takes up a little disk space.
> But it doesn't have any runtime cost for server environments. For
> applets or "webstart" applications, yes. But that's not jakarta's focus.
> And as noted above, those application developers are welcome to select
> and repackage the classes they desire.
>
> > >
> > >
> > I am sure all the weirdest collections were used at least once. But
> > should that be enough?
>
> It's a grey area. But if the regular developers on a project are willing
> to create and maintain the code (including writing unit tests for it),
> then I reckon I'd trust their judgement.
>
> > >
> > But ONLY those not-in-JDK need unmodifiable decorators.
> >
> > Completness is often a weak reason for too much featuritis/crap.
>
> This sounds like a good guideline to me. I agree that in general stuff
> should be added only when there is a demand for it.
>
> However quite a lot of people are too shy to ask for stuff. And of
> course when they want it, they want it *then*, not to wait for the next
> release. So quite a lot of the time even when there *is* demand for a
> feature, no email or bugzilla request is made [I'm guilty of this
> myself]. So the project developers should use their judgement on whether
> features are actually likely to be used.
>
>
> > I am not sure that being able to extract the decorated object is a
> > feature. I would qualify it as a Bug
> > in most of the contexts where I use such thing.
> > - E.g.: in a IoC design, if I give to some component a UnmodifiableMap
> > it is usually because I
> > REALLY, REALLY want to avoid any possibility of that component's
> > code being able to change
> > the decorated Map.
>
> Well, it's always possible; anything the collections API can do, the
> user could have done anyway.
>
> > This means that I am not against having even the incredible Flat3Map
> > packaged in some way. My
> > problem is that I am overloaded with so much stuff if I want to use the
> > most "obvious" and
> > "common" collections.
> >
> > My dream is that Collections would be split in smaller subprojects,
> > corresponding to smaller
> > packages (and docs/javadocs) to deal with. A big all-in-one package,
> > compatible with the current
> > monster-jar should still exist.
>
> Yes, but that introduces complexity in another manner. Is having one
> library with 100 classes better or worse than 10 libraries with 10
> classes each?
>
> To learn what facilities are available in those 10 libraries, you would
> have to go to 10 different websites and browse 10 different lots of
> javadoc. Just see the commons FAQ for a user request to provide the
> whole of commons as a single set of javadoc.
>
> And my server app which uses a number of different collections would
> need 10 jars in the classpath not just one. And I would have to track
> dependencies between my app and 10 different projects, not just one.
>
> >
> > I would just like to have an easy "standard" alternative to the monster
jar.
> >
> > >
> > >
> > IMO, dividing would still make everybody happy.
> > =:o)
>
> It wouldn't please me. See, the collections maintainers just can't win
> :-)
>
> >
> > >Having said all that, it must be born in mind that [collections], like
> > >[lang], operates in two ways. The first is as a jar file dependency.
For
> > >that it requires a good package layout, complete and logical set of
classes
> > >(no holes) and clear docs.
> > >
> > >
> > This (no holes) thing is also something that must be taken with a grain
> > of salt...
>
> Yes, I would agree. The goal of "completeness" is sometimes
> counter-productive.
>
>
> > Seriously, not only do I see the primites out, but I also have the idea
> > that everything is better
> > placed and fits better together. Last time I was just going to quit
> > using Collections, now I am taking
> > the time to bother you into providing alternative packaging.
> > =:oD
>
> I appreciate your comments and point of view. I'm sure Stephen does too.
>
> Unfortuately, the kind of stuff I want to do with collections causes me
> to lean in the other direction - to request that collections not be
> fragmented into any more projects than it already is.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Thu, 2004-04-22 at 08:48, paulo gaspar wrote:
> Stephen Colebourne wrote:
> >>IMO, the collections package:
> >>1) should have really commonly used collections that are missing on the
> >>java.util package and also
> >> some usefull collections building blocks for especial cases;
> >>2) should NOT be a contest to implement all possible classes that have
> >>something to do (even
> >> remotedly) with collections, doesn't mater how special they might be.
I think that collections is fine as it is.
Jakarta's whole goal is to provide "server" components for java. If
these happen to also be useful for applets, then that is great. However
I believe that those people who want to use jakarta components in
environments that are constrained by network bandwidth or RAM or disk
space are responsible for themselves repackaging the bits they want.
Remember, if anyone wants to write an applet and use some of the great
collection classes in commons-collections, there is nothing to prevent
them from selecting the classes they want and creating a custom jar
file.
>
> ..but #2 is a very strong perception, smelling like "real reality", to me.
And it smells differently to me. I like having a single project that
collects a number of collections together. In fact, I would probably
have preferred to have the primitive collections in the same project and
jar.
Having "unused" classes present in a jar takes up a little disk space.
But it doesn't have any runtime cost for server environments. For
applets or "webstart" applications, yes. But that's not jakarta's focus.
And as noted above, those application developers are welcome to select
and repackage the classes they desire.
> >
> >
> I am sure all the weirdest collections were used at least once. But
> should that be enough?
It's a grey area. But if the regular developers on a project are willing
to create and maintain the code (including writing unit tests for it),
then I reckon I'd trust their judgement.
> >
> But ONLY those not-in-JDK need unmodifiable decorators.
>
> Completness is often a weak reason for too much featuritis/crap.
This sounds like a good guideline to me. I agree that in general stuff
should be added only when there is a demand for it.
However quite a lot of people are too shy to ask for stuff. And of
course when they want it, they want it *then*, not to wait for the next
release. So quite a lot of the time even when there *is* demand for a
feature, no email or bugzilla request is made [I'm guilty of this
myself]. So the project developers should use their judgement on whether
features are actually likely to be used.
> I am not sure that being able to extract the decorated object is a
> feature. I would qualify it as a Bug
> in most of the contexts where I use such thing.
> - E.g.: in a IoC design, if I give to some component a UnmodifiableMap
> it is usually because I
> REALLY, REALLY want to avoid any possibility of that component's
> code being able to change
> the decorated Map.
Well, it's always possible; anything the collections API can do, the
user could have done anyway.
> This means that I am not against having even the incredible Flat3Map
> packaged in some way. My
> problem is that I am overloaded with so much stuff if I want to use the
> most "obvious" and
> "common" collections.
>
> My dream is that Collections would be split in smaller subprojects,
> corresponding to smaller
> packages (and docs/javadocs) to deal with. A big all-in-one package,
> compatible with the current
> monster-jar should still exist.
Yes, but that introduces complexity in another manner. Is having one
library with 100 classes better or worse than 10 libraries with 10
classes each?
To learn what facilities are available in those 10 libraries, you would
have to go to 10 different websites and browse 10 different lots of
javadoc. Just see the commons FAQ for a user request to provide the
whole of commons as a single set of javadoc.
And my server app which uses a number of different collections would
need 10 jars in the classpath not just one. And I would have to track
dependencies between my app and 10 different projects, not just one.
>
> I would just like to have an easy "standard" alternative to the monster jar.
>
> >
> >
> IMO, dividing would still make everybody happy.
> =:o)
It wouldn't please me. See, the collections maintainers just can't win
:-)
>
> >Having said all that, it must be born in mind that [collections], like
> >[lang], operates in two ways. The first is as a jar file dependency. For
> >that it requires a good package layout, complete and logical set of classes
> >(no holes) and clear docs.
> >
> >
> This (no holes) thing is also something that must be taken with a grain
> of salt...
Yes, I would agree. The goal of "completeness" is sometimes
counter-productive.
> Seriously, not only do I see the primites out, but I also have the idea
> that everything is better
> placed and fits better together. Last time I was just going to quit
> using Collections, now I am taking
> the time to bother you into providing alternative packaging.
> =:oD
I appreciate your comments and point of view. I'm sure Stephen does too.
Unfortuately, the kind of stuff I want to do with collections causes me
to lean in the other direction - to request that collections not be
fragmented into any more projects than it already is.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by "matthew.hawthorne" <ma...@apache.org>.
Stephen Colebourne wrote:
> Sometime, I think this is what many people looking at collections don't
> appreciate. Implementing the collection interfaces, especially the maps, can
> be really hard.
You can say that again -- I think my head is still spinning from working
on a BidiMap implementation during the pre-3.0 days. I find that type
of low-level programming to be incredibly difficult.
Because of keySet and entrySet, Maps can require you to implement 2 or 3
anonymous inner Iterators just to create a single implementation! And
then to figure out what to do when someone invokes Iterator.remove()...
ugh...
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[events] Re: [collections] Size and scope issues
Posted by Herve Quiroz <he...@esil.univ-mrs.fr>.
On Mon, Apr 19, 2004 at 10:50:39PM +0100, Stephen Colebourne wrote:
> From: "Noel J. Bergman" <no...@devtech.com>
> > > > - ALL the Unmodifiable crap
> >
> > > I can understand this. The reason the classes exist is for
> > > completeness and practicality. [collections] has interfaces
> > > that are not in the JDK, and they need unmodifiable decorators
> >
> > Steve, this is where I was wondering about the approach used in the
> [events]
> > message posted today. Would that help, if applied consistently across
> > [collections]?
> Not really. Proxying would require a simple matching straegy.
>
> However, each collection has its own tricks when it comes to writing
> decorators. For an unmodifiable map for example, you must trap the main map,
> the keySet, the values collection and the entrySet. Plus you must trap the
> setValue on exposed MapEntry objects from the entrySet iterator and the
> toArray.
For maps, I agree with you.
Still, for PredicatedCollection, I think a simple proxy would do
wonders.
Another possible use would be to have "interceptor" (borrowed from
[HiveMind]) proxies, that performs not only checking (as for
predicates), but also post- or pre- processing. I can't think of any
example right now... maybe to implement some caching mechanism ontop of
an existing collection?
Stephen, I am currently packing my classes. I'll send you a link so you
may have a look at my proxy stuff.
Herve
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Size and scope issues
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Noel J. Bergman" <no...@devtech.com>
> > > - ALL the Unmodifiable crap
>
> > I can understand this. The reason the classes exist is for
> > completeness and practicality. [collections] has interfaces
> > that are not in the JDK, and they need unmodifiable decorators
>
> Steve, this is where I was wondering about the approach used in the
[events]
> message posted today. Would that help, if applied consistently across
> [collections]?
Not really. Proxying would require a simple matching straegy.
However, each collection has its own tricks when it comes to writing
decorators. For an unmodifiable map for example, you must trap the main map,
the keySet, the values collection and the entrySet. Plus you must trap the
setValue on exposed MapEntry objects from the entrySet iterator and the
toArray.
Sometime, I think this is what many people looking at collections don't
appreciate. Implementing the collection interfaces, especially the maps, can
be really hard.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] Size and scope issues
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > - ALL the Unmodifiable crap
> I can understand this. The reason the classes exist is for
> completeness and practicality. [collections] has interfaces
> that are not in the JDK, and they need unmodifiable decorators
Steve, this is where I was wondering about the approach used in the [events]
message posted today. Would that help, if applied consistently across
[collections]?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org