You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Morgan Delagrange <md...@yahoo.com> on 2002/02/19 17:28:22 UTC
Collections 2.0? (Collections 1.1 RIP)
It looks like the next Collections release may have to be a Major Release after all. Last night, I realized that if SequencedHashMap no longer extends from HashMap, then you will not be able to cast the new LRUMap to that class. So our options seem to be:
1. Keep HashMap as the superclass of SequencedHashMap
2. Do not implement LRUMap as a subclass of SequencedHashMap
3. Bite the bullet on a 2.0 release
My preference would be option #3. Of course, if 1 or 2 occur then a 1.1 release is still a possibility.
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Collections 2.0? (Collections 1.1 RIP)
Posted by Paulo Gaspar <pa...@krankikom.de>.
+1
> -----Original Message-----
> From: Michael Smith [mailto:michael@iammichael.org]
> Sent: Wednesday, February 20, 2002 5:48 AM
> To: Jakarta Commons Developers List
> Subject: RE: Collections 2.0? (Collections 1.1 RIP)
>
>
> bayard@generationjava.com wrote:
> > > > I suppose it wasn't explicitly stated though. But I agree here.
> > > > Collections should be based on the 1.2 Collection APIs.
> > >
> > > Agreed - I don't think it makes much sense to have 1.1
> > support for a library
> > > based on Java 2 collections. (Though with some Ant search &
> > replace hacks we
> > > could build a version of commons-collections that works on
> > the Java 1.1
> > > distro of Java 2 collections - but do we really need to go there?)
> >
> > My original question was not so much, do we support Collections in 1.2
> > rather than 1.1, but do we ensure that all API interaction takes
> > Iterator/List/Map rather than Enumeration/Vector/Hashtable?
> >
> > (Except for those components that are there to bridge, ie)
> > EnumerationIterator).
>
> Yes, I believe Iterator/List/Map/etc. should be used rather than
> Enumeration/Vector/Dictionary in the collections API for the same
> reasons. If someone has an Enumeration and wants to call another
> collections api, they just wrap the Enumeration in an
> EnumerationIterator. Hashtable and Vector already implement the
> appropriate interface (Map and List), so that's not a problem. And I
> don't think we really need to care about someone that extends from
> Dictionary.
>
> regards,
> michael
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Collections 2.0? (Collections 1.1 RIP)
Posted by Michael Smith <mi...@iammichael.org>.
bayard@generationjava.com wrote:
> > > I suppose it wasn't explicitly stated though. But I agree here.
> > > Collections should be based on the 1.2 Collection APIs.
> >
> > Agreed - I don't think it makes much sense to have 1.1
> support for a library
> > based on Java 2 collections. (Though with some Ant search &
> replace hacks we
> > could build a version of commons-collections that works on
> the Java 1.1
> > distro of Java 2 collections - but do we really need to go there?)
>
> My original question was not so much, do we support Collections in 1.2
> rather than 1.1, but do we ensure that all API interaction takes
> Iterator/List/Map rather than Enumeration/Vector/Hashtable?
>
> (Except for those components that are there to bridge, ie)
> EnumerationIterator).
Yes, I believe Iterator/List/Map/etc. should be used rather than
Enumeration/Vector/Dictionary in the collections API for the same
reasons. If someone has an Enumeration and wants to call another
collections api, they just wrap the Enumeration in an
EnumerationIterator. Hashtable and Vector already implement the
appropriate interface (Map and List), so that's not a problem. And I
don't think we really need to care about someone that extends from
Dictionary.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Collections 2.0? (Collections 1.1 RIP)
Posted by ba...@generationjava.com.
> > I suppose it wasn't explicitly stated though. But I agree here.
> > Collections should be based on the 1.2 Collection APIs.
>
> Agreed - I don't think it makes much sense to have 1.1 support for a library
> based on Java 2 collections. (Though with some Ant search & replace hacks we
> could build a version of commons-collections that works on the Java 1.1
> distro of Java 2 collections - but do we really need to go there?)
My original question was not so much, do we support Collections in 1.2
rather than 1.1, but do we ensure that all API interaction takes
Iterator/List/Map rather than Enumeration/Vector/Hashtable?
(Except for those components that are there to bridge, ie)
EnumerationIterator).
Bay
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Collections 2.0? (Collections 1.1 RIP)
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Michael A. Smith" <mi...@iammichael.org>
> Someone recently brought up comparators. That would probably be a good
> addition.
Agreed - some good common comparators sound good.
> There's probably others as well -- haven't seen a splay-tree
> implementation yet, but does anyone actually use them? :)
:)
> I thought that was implied by the intro to the collections component:
>
> http://jakarta.apache.org/commons/collections.html
>
> I suppose it wasn't explicitly stated though. But I agree here.
> Collections should be based on the 1.2 Collection APIs.
Agreed - I don't think it makes much sense to have 1.1 support for a library
based on Java 2 collections. (Though with some Ant search & replace hacks we
could build a version of commons-collections that works on the Java 1.1
distro of Java 2 collections - but do we really need to go there?)
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Dependency question
Posted by Daniel Rall <dl...@finemaltcoding.com>.
<ba...@generationjava.com> writes:
> On that note, how about a Lang sub-project for core-language helpers.
> Number/Date/String/Url/File helpers etc.
This is basically what I see Util as, a little bit of java.lang,
java.util, and perhaps java.text.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Dependency question
Posted by ba...@generationjava.com.
How do dependencies work withing the Commons project?
More specifically, I would like to make the Collections sub-project
dependent on the Util sub-project. This seems bad for two reasons to me:
1) Unnecessary dependency is scary and should be trod lightly with.
2) Util is sandboxed atm with no sign of promotion.
The things I'm looking to add are:
1) A comparators sub-package containing 7 initial comparators. One of these uses
Soundex, which is in the Util sub-project. There's also a BeanComparator
which I think is very cool, but I think its baggage would replicate too
much code from other Jakarta projects so I need to refactor it probably.
A couple of the comparators are dependant on the registries below.
2) Registry structure. Various types of registry objects, such as
ClassRegistry, SimpleRegistry, ThreadRegistry(replicates ThreadLocal I
think) etc. I've not noticed this type of functionality as another
package.
Or should I just dump the stuff in Util? The great breeding ground for
bogged down components? :)
On that note, how about a Lang sub-project for core-language helpers.
Number/Date/String/Url/File helpers etc.
Bay
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Collections 2.0? (Collections 1.1 RIP)
Posted by "Michael A. Smith" <mi...@iammichael.org>.
On Tue, 19 Feb 2002, Morgan Delagrange wrote:
> > Is there a whole list of 'things that ought to be done' we could compile
> > for Collections? Then target 2.0 with an aim to clear those up?
>
> +1. I'm willing to track (informally) that kind of information.
I read that question as "is there an existing list" and I believe the
answer to that question is: no, but Morgan is proposing to create and
manage that list so that we can push towards a 2.0 release.
> > Hell, Collections is pretty small, we could go through it a component at a
> > time and solicit opinions, then solve and tick off, then declare 2.0?
>
> If you want. That sounds like overkill to me. No need to go looking for
> work to do, I'd prefer to let folks just scratch their itches.
That's kind of what I started with my patches. Call it my itch. I'm
bored, and looking for a project to keep me busy at home. So I started
going through each collections class, peer-review style.
However, I think the key here though is not reviewing the components that
already exist, but what else should we add. That is, what other types of
collections should we be including in a Collections 2.0 release? Part of
that answer is figuring out what exists in other jakarta projects that
could be pulled into commons so that other jakarta projects can reuse
them.
Someone recently brought up comparators. That would probably be a good
addition. There's probably others as well -- haven't seen a splay-tree
implementation yet, but does anyone actually use them? :)
> > Is there a list of changes from 1.0 that are being made to 2.0?
>
> Please send any changes of note to the list. Here's what I know of:
>
> - New collection: SynchronizedHashMap
> - Reimplementation and bug fixes to LRUMap (probably)
> - LRUMap can no longer be cast to a HashMap (probably)
>
> I also know of some other new classes, like the Bag classes, but I would
> prefer the contributors to send a short note on their purpose and status,
> rather than having one of the uninitiated comb through the CVS logs.
Doesn't seem like much of an addition to call it a 2.0 release, but I
suppose that's what's required because of the incompatibilities. :) Maybe
we'll find some more collection code that can be added before a 2.0
release.
> > Should 2.0
> > enforce a Java 1.2 usage?
>
> Not sure I follow here. Maybe you mean something like, "Should we note in
> our docs that any class in Collections may rely on Java 2 Collections in
> future releases?" If so, then definitely yes, let's include that in the
> contract for the product.
I thought that was implied by the intro to the collections component:
http://jakarta.apache.org/commons/collections.html
I suppose it wasn't explicitly stated though. But I agree here.
Collections should be based on the 1.2 Collection APIs.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Collections 2.0? (Collections 1.1 RIP)
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, February 19, 2002 11:17 AM
Subject: Re: Collections 2.0? (Collections 1.1 RIP)
>
> While my question is for new functionality I'd like to get in before a
> 2.0 release, Berin's raises a good point.
Don't forget, you can add new functionality in a Minor Release too (but not
a bug-fix release), as long as it is not vetoed and does not break existing
interfaces.
> Is there a whole list of 'things that ought to be done' we could compile
> for Collections? Then target 2.0 with an aim to clear those up?
+1. I'm willing to track (informally) that kind of information.
> Hell, Collections is pretty small, we could go through it a component at a
> time and solicit opinions, then solve and tick off, then declare 2.0?
If you want. That sounds like overkill to me. No need to go looking for
work to do, I'd prefer to let folks just scratch their itches.
> Is there a list of changes from 1.0 that are being made to 2.0?
Please send any changes of note to the list. Here's what I know of:
- New collection: SynchronizedHashMap
- Reimplementation and bug fixes to LRUMap (probably)
- LRUMap can no longer be cast to a HashMap (probably)
I also know of some other new classes, like the Bag classes, but I would
prefer the contributors to send a short note on their purpose and status,
rather than having one of the uninitiated comb through the CVS logs.
> Should 2.0
> enforce a Java 1.2 usage?
Not sure I follow here. Maybe you mean something like, "Should we note in
our docs that any class in Collections may rely on Java 2 Collections in
future releases?" If so, then definitely yes, let's include that in the
contract for the product.
> Just ideas..
>
> Bay
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Collections 2.0? (Collections 1.1 RIP)
Posted by ba...@generationjava.com.
While my question is for new functionality I'd like to get in before a
2.0 release, Berin's raises a good point.
Is there a whole list of 'things that ought to be done' we could compile
for Collections? Then target 2.0 with an aim to clear those up?
Hell, Collections is pretty small, we could go through it a component at a
time and solicit opinions, then solve and tick off, then declare 2.0?
Is there a list of changes from 1.0 that are being made to 2.0? Should 2.0
enforce a Java 1.2 usage?
Just ideas..
Bay
On Tue, 19 Feb 2002, Berin Loritsch wrote:
> bayard@generationjava.com wrote:
> > Where should comparators go by the way?
> >
> > in
> >
> > collections.compare
> > collections.comparator
> > collections
> > comparator
> > compare
>
>
> If you upgrade to Collections 2.0, then you might as well
> upgrade the PriorityQueue interface and implementing classes
> to work with Objects instead of Comparables. That was what
> the intent was.
>
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Collections 2.0? (Collections 1.1 RIP)
Posted by Berin Loritsch <bl...@apache.org>.
bayard@generationjava.com wrote:
> Where should comparators go by the way?
>
> in
>
> collections.compare
> collections.comparator
> collections
> comparator
> compare
If you upgrade to Collections 2.0, then you might as well
upgrade the PriorityQueue interface and implementing classes
to work with Objects instead of Comparables. That was what
the intent was.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Collections 2.0? (Collections 1.1 RIP)
Posted by ba...@generationjava.com.
Where should comparators go by the way?
in
collections.compare
collections.comparator
collections
comparator
compare
???
I had a couple of simple ones I wanted to commit and a more complex one
that might take a fair bit more effort to merge with the Jakarta
Bean-reflection system. (I have my own, but I don't understand the Jakarta
one yet to see how similar they are).
Bay
On Tue, 19 Feb 2002, Morgan Delagrange wrote:
> It looks like the next Collections release may have to be a Major Release after all. Last night, I realized that if SequencedHashMap no longer extends from HashMap, then you will not be able to cast the new LRUMap to that class. So our options seem to be:
>
> 1. Keep HashMap as the superclass of SequencedHashMap
>
> 2. Do not implement LRUMap as a subclass of SequencedHashMap
>
> 3. Bite the bullet on a 2.0 release
>
> My preference would be option #3. Of course, if 1 or 2 occur then a 1.1 release is still a possibility.
>
> - Morgan
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>