Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 35546 invoked from network); 22 Feb 2002 00:02:04 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Feb 2002 00:02:04 -0000 Received: (qmail 12922 invoked by uid 97); 22 Feb 2002 00:02:08 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 12906 invoked by uid 97); 22 Feb 2002 00:02:07 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 12895 invoked from network); 22 Feb 2002 00:02:07 -0000 Date: Thu, 21 Feb 2002 19:01:52 -0500 (EST) From: X-X-Sender: To: Jakarta Commons Developers List , Morgan Delagrange Subject: Re: [COLLECTIONS] 2.0 Release digest 02/21/2002 In-Reply-To: <009901c1bb22$1de9d370$8905050a@eb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Can a movement of those classes in Util which are seen as Collections classes be made before 2.0? It seems to mainly be a check from Collections that yes the Utils ones are copys, and then an import of StringStack and BufferCache or some such. Maybe a rewrite of BufferCache to fit it in. I may not understand what will be in Collections 2.0 well enough yet though. Is it everything in Collections, or do you choose those components that are worthy? Would transferring the above componetns and considering the location or compare/ and lru/ sub-pakcages cause a problem with Collections 2.0? Bay On Thu, 21 Feb 2002, Morgan Delagrange wrote: > Hi all, > > I'm going to work on a Collection 2.0 release digest, where I'll track the > progress toward release time. I'll post updates to the digest occasionally > on the list. Post any additions to the release tasks to the list, and I > will make sure they are included in the digest. > > - Morgan > > > COLLECTIONS 2.0 DIGEST (02/21/2002) > ----------------------------------------------------------- > > The following is a synopsis of the Collections 2.0 release > effort to date. > > ISSUES > --------------- > > All Bag classes: Still needs details in the STATUS document > > DoubleOrderedMap: Still needs details in the STATUS document > > MultiMap/MutliHashMap: Still needs details in the STATUS document > > SequencedHashMap: Still needs details in the STATUS document > > SingletonIterator: Still needs details in the STATUS document > > > PENDING COLLECTIONS > ------------------- > > Collections from the Commons UTIL package: Need to be integrated > into Collections 2.0. Duplicates must be resolved. > > DirtyFlagMap: Per the email sent by James House > (http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=101406634514652&w=2). > Will be reviewed by Michael Smith > > "Comparators" proposal: Commit proposed comparators to CVS for review. > > > RELEASE NOTES ROUGH DRAFT: > -------------------------- > > > NEW COLLECTIONS: > ---------------- > > > > > CHANGED COLLECTIONS: > -------------------- > > LRUMap > ------ > > LRUMap has been reimplemented as a subclass of > SynchronizedHashMap. The new implementation of > LRUMap should be faster, and it also offers true LRU > capabilities; now any get(Object) or > put(Object,Object) from this collection > promotes the key to the Most Recently Used position. > > LRUMap 2.0 compatibility changes: > - LRUMap can no longer be cast to a HashMap. > - The removeLRU() method now has a different > signature, and is no longer public. There is > no direct replacement for this method. > - "Externalized" LRUMap 1.0 Objects cannot be > read by LRUMap 2.0. > > New features: > - True LRU algorithm. > - New methods from SequencedHashMap superclass. > - processRemovedLRU(Object key, Object value) method > allows subclasses to perform custom actions on > keys and values that are expunged from the Map. > > Bugs fixed: > - calling setMaximumSize(int) will remove excess LRUs > when the current size of the Map exceeds the new > maximum size > > > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: