While everyone is free to vote for whatever they want for whatever reason they wish, voting -1 to a proposal because it will create another jar doesn't seem right to me. How hard is it, really, to deal with another jar. You add another entry to your project.xml. You add another file to a directory. I understand that some production environments are not this free-spirited, but there has to be a limit.
Take a look at the codebase for [collections]. It's monstrous. Think about the un-object-oriented-ness required for building a primitive collections library. There already are an unbelievable amount of primitive classes, and there will continue to be more.
The scope and purpose of the [pcollections] and [collections] components are quite different. The first is extensions and utilities for working with the collections framework. The second involves the creation a new primitive implementation which is similar to the collections framework. In my opinion, there will not be much overlap.
I've done some pseudo-ranting here, and I apologize, but my point is: These projects are more different than they appear, and adding another jar is a small price to pay for the proper separation and encapsulation of code. When there are too many lines of code, it's good to split one class into many. When there are too many classes, and a distinct separation appears between groups of those classes, it may be good to split one component into many.
Gary Gregory wrote:
1-, I think...
I am in favor of primitives support IN [collection] proper, /especially/ since 1.5 will not address this issue. For a feature that 1.4 or 1.5 would address I would see as a good thing a separate Jar for pre-1.4 or pre-1.5 setups. For example, in [lang], having the nested exception classes in the jar is obviously duplicative in a 1.4 setup.
Now, I do recall some thread on this list about primitives collections but I do not recall if any agreement came on package names or 'jaring'.
My concerns are (feel free to pour gas and set on fire any of these):
(1) One more Jar file to keep track of on the class path, with this email list, with our product build, our customers, etc. All the pain that comes with having yet one more jar dependency in a product.
(2) Conceptually, [collections] is one nice lump. Splitting it for
collections of primitives vs. Objects is a subtlety I do not want 2 jars
for, 2 packages fine but not two jars.
Will one jar depend on the other?
Gary
-----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 17:06 To: Jakarta Commons Developers List Subject: [VOTE] New commons proper component - pcollections
The [collections] component has been housing unreleased, but stable primitive collections code for some time. These are collections that store primitive arrays behind the scenes instead of objects. (Note that JDK1.5 does NOT address the need for these classes).
Following discussion within the [collections] component on the best release strategy, we would like to create a new commons-PROPER component to house the code. The aim is to give this useful code room to grow without impacting the widely used main [collections] (object-based) component.
It is important to emphasise that this is not new code - it is stable and ready for release. Thus commons-proper, rather than the sandbox, is the appropriate place for the new component.
The proposal is attached for the new component 'pcollections'. (No one likes this name, but we haven't found a better one).
Please vote as to whether you support this new commons-PROPER component. [ ] +1 Yes, lets create [pcollections] [ ] +0 [ ] -0 [ ] -1 No, I oppose this because....
Stephen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
