commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <...@apache.org>
Subject RE: [collections] Avalon excalibur collections migration status
Date Mon, 15 Jul 2002 17:06:07 GMT
On Mon, 15 Jul 2002, Jack, Paul wrote:
> To this list I'd add:
> 
> - Resolve all outstanding bugs in Bugzilla.  This means:

That's what "fix all known bugs" meant.  

> * Resolve the Bag controversy (the Bag interface violates 
> Collection).  Either reimplement DefaultMapBag so that it 
> conforms to Collection and redocument Bag, or just redocument
> Bag so that the violations are clearly marked.

I think I'd like to see just documentation for this release on this 
issue, with a note saying that it will be brought into compliance in a 
future release.  That way, backwards compatibilty is maintained and we 
can have a 2.1 release rather than a 3.0 release.  Something about 
always having major releases and no minor releases bothers me.

> * Do something with the Fast* collections.  At minimum, their
> documentation should indicate that they are not cross-platform
> and are therefore rather dangerous.  The documentation should
> also indicate that their collection views do not operate per
> contract.  However, I'd rather actually fix the collection views
> so that they do pass all the TestMap tests in fast mode.

Your patch is still in my todo list.  As for the collection views, I 
thought there already was documentation on their behavior, but I'll 
revisit it and improve upon the documentation as necessary.

> * Do something with SoftRefHashMap.  Its current form is "all 
> kinds of wonky".  All of its little strangenesses should be 
> documented (ie, the containsKey(Object) and containsValue(Object)
> methods might disagree for a key/value pair).  Frankly I'd 
> deprecate the class and provide a more efficient version (one
> that uses a ReferenceQueue) and a more well-defined version (one
> that behaves much like a WeakHashMap).  

Does the version you wrote and submitted do these things (I think you 
called it ReferenceMap)

> * Fix MultiHashMap's values() collection view.

I don't remember what the issue was on this one.  

> - Document MultiMap and MultiHashMap.  For instance, the get(Object)
> method either returns null or a collection.  If it ever returns a 
> collection for a given key, it will never again return null.  (Actually
> that strikes me as a memory leak).  

yes, it possibly is.  I don't think it would be backwards compatible to 
drop the collection and start returning null if there aren't any more 
instances.  It *would* be compatible if we started returning a freshly 
created empty collection though.


regards,
michael

p.s. As much as I thought I would have time this past weekend to work on 
the DynamicBucketMap, it seemed to all disappear before I could even 
start.

> -Paul
> 
> 
> > TODO LIST BEFORE COLLECTIONS CAN RELEASE A NEW VERSION
> > 
> > A release of commons collections should be completed before avalon 
> > excalibur users can fully depend on the collections code 
> > base.  Before 
> > we can have a collections release, we will need to minimally:
> > 
> >  - Ensure compliance with the naming conventions found in the 
> > developers
> >    guide
> > 
> >  - Document new classes/interfaces in package.html
> > 
> >  - Add of @since tags for all the new classes (with 
> > appropriate version 
> >    number, probably 2.1)
> > 
> >  - Fix all known bugs (or at least document them in the release notes)
> > 
> > Ideally, a collections release should also:
> > 
> >  - Add a DynamicBucketMap to accompany StaticBucketMap (I'm 
> > working on 
> >    this now and should be done by the end of the weekend).  
> > 
> >  - Add lots of new decorators (e.g. synchronizedBag) and appropriate
> >    tests (I believe Paul Jack has been working on some of these).
> > 
> >  - Use a *single* coding convention for all the collections classes,
> >    rather than the hodgepodge of styles currently used (at least most
> >    classes are self-consistent). 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 


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


Mime
View raw message