RE: [Collections] Naming conventions

> we could even make them public classes and allow users to > extend them on > their own (using the XXXUtils.whatever methods as convenience methods) Well, yes...but we'd be adding like 30 classes to the public API. Maybe have a separate package for decorators? > FactoryUtils could still be u

RE: [Collections] Naming conventions

> I personally like the Lists, Sets, Collections, etc naming, > too. We could put pass-through methods to > java.util.Collections on the commons.Collections class. > That way we can have our cake and eat it too. I definitely agree that code like this is nicer: Bag bag = Bags.synchronizedBa

RE: [Collections] Naming conventions

> 2) Subclassing would be more complex. Currently each > Predicate decorator > implementation extends another based on the interface > hierarchy. In order to > continue this, the static nested classes would need to be > package scoped, > not private. Not a big issue, but it should be noted. I'

RE: [Collections] Naming conventions

Here's an idea. We can make the source more manageable and effectively limit the number of public classes by breaking my One Decorator Class To Rule Them All into smaller ones based on subinterface: Bags (for SortedBags too) predicatedBag predicatedSortedBag synchronizedBag

RE: [Collections] Naming conventions [was ComparableComparator - nulls OK]

giant > > > WrapperUtils? > > > > I would encourage the use of the term "Decorator" instead > > of "Wrapper". The more concise we can be with language, > > the better IMHO (Assuming everything that util class would > > only add decorat

RE: [PATCH][Collections] New testing framework, junit compatible

> I hate ask you to do more work, Here to help. :) > but can you separate the changes to the Bag implementations from > the improvements to the testing framework? Well, not really. The problem is that the old Bag implementations will fail many of the new tests in TestCollection, because th

RE: Collections

> Filtering collections, that guarantees that only objects that > matches an ObjectFilter (sorry, I mean Predicate) are added? Check the latest code in CVS; there's already a PredicateUtils that does this. (But it is a great idea!) > TypeFilter(Predicate), that only evaluates to true if the

RE: [Collections] ComparableComparator - nulls OK

Actually, that's a good point. There are some other considerations behind the long convention... Technically it's possible for a collection to implement both Set and Bag (getCount() would always return 1 or 0; uniqueSet would return an unmodifiable view of itself)... I'm not saying such an impl

[PATCH][Collections] New testing framework, junit compatible

http://www.geocities.com/apachecollections/june10 Rewrote BulkTest so that it extends TestCase. It now provides a static makeSuite(Class) method that can be used to create a TestSuite that's displayed as a hierarchy in the swingui. The other code's all the same, except less files needed to be

RE: [Collections] ComparableComparator - nulls OK

> I too like the ComparatorUtils concept outlined below. > However, we might > want to consider whether the method names are nullFirst(Comparator) or > nullFirstComparator(Comparator) etc. I raise this because > PredicateUtils > uses the latter at the moment, and it would be nice to be > consis

[SUBMIT][Collections] ComparatorUtils

ComparatorUtils.java Description: Binary data

RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean?

s in another comparator, other do the toLowerCase call... > > ERic > > -Original Message- > From: Jack, Paul [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 4:45 PM > To: 'Jakarta Commons Developers List' > Subject: RE: [COLLECTIONS/BEANUTILS] Is th

RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean?

FYI, java.lang.String.CASE_INSENSITIVE_ORDER does what your LowercaseComparator does, but somewhat more efficiently. -Paul > -Original Message- > From: Eric Pugh [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 1:35 PM > To: 'Jakarta Commons Developers List' > Subject: RE: [COL

RE: [Collections] ReadOnly Collection decorators

Um, the JDK already provides what you're looking for: java.util.Collections.unmodifiableSet(Set set) Collections.unmodifiableList(List list) Collections.unmodifiableMap(Map map) and so on. We should probably provide similar things for Bag, SortedBag and MultiMap though. -Paul > -Original

RE: [PATCH][Collections] New testing framework, patch #1

> You've put a lot of work into getting these tests up and > running, and it > has exposed some problems with existing implementations, so your work > isn't without merit. In fact, I'm inclined to commit it, I would just > rather see something that utilizes JUnit's TestSuite (by subclass > proba

[PATCH][Collections] New collections testing framework, attempt #3

Okay, this is a cumulative patch; it includes the previous two. The point of this patch is that TestMap is now hardcore. It fully tests its collection views, by running through the tests defined in TestSet and TestCollection on keySet(), entrySet() and values(). It also fully tests that colle

RE: [Collections] ComparableComparator - nulls OK

I like the idea of having the functionality provided by NullFirstComparator and NullLastComparator, but I have an additional suggestion. Currently, all of the classes in the comparators subpackage are simple, and very useful. However, it seems that they'd most often be used in conjunction with

[PATCH][Collections] SequencedHashMap collection view bugs

Bugs fixed: 1. keySet().remove(Object) incorrectly returned false after a successful removal of a null key. 2. The removeAll(Collection) and retainAll(Collection) methods of the collection views (keySet, entrySet and values) were not updating the modCount; therefore an iterator over a collecti

RE: cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/primitives TestFloatArrayList.java TestAll.java

Hi, just so you know, I'm currently working on a TestList that your primitive collection TestCases will be able to extend... Might save you some work. -Paul -- To unsubscribe, e-mail: For additional commands, e-mail:

[PATCH][Collections] Bug fix for Bug#9467

Altered the contract of Bag to conform to Collection. Altered the implementations in DefaultMapBag to conform to Collection. -Paul bug9467_patch.diff Description: Binary data -- To unsubscribe, e-mail: For additional commands, e-mail:

[PATCH][Collections] New testing framework, patch #2

(This patch can be applied independently of patch #1). Revamped TestCollection. Most of the old tests relied on add() and addAll() to initially populate a collection. This won't work for map collection views because they don't support the add() and addAll() operations. I also made TestCollect

[PATCH][Collections] New testing framework, patch #1

Okay, so the goal was to be able to modularize the tests in such a way that objects that return a collection or map could have those return values tested using TestMap, TestCollection etc. How I decided to handle that was to create a new implementation of junit.framework.Test, that allows you to

RE: [collections] collections of primitives?

Looks good to me. I like the separate package approach, and "primitives" seems descriptive enough. -Paul > -Original Message- > From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 28, 2002 5:48 AM > To: 'Jakarta Commons Developers List' > Subject: [collections] collec

RE: [Collections][Submit] TreeNode and friends

My votes: 1. Eliminate TreeIterator. 2. Eliminate equals(), hashCode() and clone() from TreeNode. 3. Have iterator() make no guarantees about order; provide the utility methods for depth-first and breadth-first. Should the children be represented by a List or by a Collection? Seems GUI tree

RE: [PATCH][Collections] further testing code for Maps

> > It'd also be nice to reuse the same tests for different > > configurations of the same collection, eg, FastArrayList in > > fast mode vs. FastArrayList in slow mode. > > > > I'm going to go ahead and work on having fully extensible > > testing suite for collections, if you've no objections..

RE: [SUBMIT][Collections] ReferenceMap, take 2

> Just an ideais it possible to write ReferenceMap as a > wrapper around > another Map? If so, then we could have ReferenceSortedMap, > ReferenceList > etc. all within ReferenceCollections. Yes, but not efficiently. For weak or soft keys, you'd have to create a bunch of Reference objects t

RE: [Collections][Submit] TreeNode and friends

Some Feedback: TreeNode: 1. Should it extend Cloneable? Some trees might not be able to be Cloneable effectively (for instance, a Btree backed by a file). 2. I think we should allow setValue to throw an UnsupportedOperationException for unmodifiable trees. 3. What's the rationale for having

RE: [PATCH][Collections] SequencedHashMap: equals, hashCode, toString

> Extending AbstractMap is not the right way to add an equals, > hashcode and > toString method. I just committed real implementations for > the methods. Was there something wrong with AbstractMap's implementations, or did you just want to keep SequencedHashMap's superclass as Object? I'm ju

[SUBMIT][Collections] ReferenceMap, take 2

Now includes a junit test, which revealed several bugs, which are now fixed. -Paul ReferenceMap.java Description: Binary data TestReferenceMap.java Description: Binary data -- To unsubscribe, e-mail: For additional commands, e-mail:

[PATCH][Collections] further testing code for Maps

Hi, I completed all the TODO and XXX items in TestMap. Some of the Map implementations (notably MultiHashMap) intentionally violate the Map contract, so I overrode some of the new methods in concrete TestMap subclasses. The only bugs the new methods found were in SequencedHashMap, which Michae

[PATCH][Collections] SequencedHashMap: equals, hashCode, toString

Index: SequencedHashMap.java === RCS file: /home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/coll ections/SequencedHashMap.java,v retrieving revision 1.9 diff -r1.9 SequencedHashMap.java 100c100 < public class Se

[SUBMIT] org.apache.commons.collections.ReferenceMap

Hi all, Had the idea for this in the thread about SoftRefHashMap, decided to code it up, as in the past I've often required maps with phantom keys or values. (Usually I just implemented them by manually placing the references in the map; but then you have do painful things every time you iterat

RE: PATCH : org.apache.commons.collections.SoftRefHashMap

> Firstly, the Map's innards should not be exposed to the user; > what is the > point of having a Map which uses a SoftReference > implementation if users of > the Map have to know this (and thus call the purge() method > when memory is > low (how will they know?)) - the Map should handle th

RE: PATCH : org.apache.commons.collections.SoftRefHashMap

> Well, the existing "purge()" method iterated through the > whole Map checking > each reference so see if it had been cleared. The new > "purge()" method > simply calls "processQueue()". This does not iterate through > the whole Map, > but instead uses the ReferenceQueue to directly get the

RE: [collections] Naming of collection wrappers classes (PredicateUtils et al)

> Thus I propose splitting PredicateUtils in two: > PredicateCollections (#1 above) > PredicateUtils (#2 above) Well, that still leaves us with the problem that PredicateUtils doesn't contain all of the predicate utils. Other ideas: 1. Move PredicateUtils.and, .or, .not, .instanceof, .TRUE a

RE: [collections] - Few more collections for the masses... (impor tant for Struts view objects, maybe other projects)

> 1) What 8 interfaces?... There's only 2 that are valid. Can't the reserve behavior be applied to: 1. java.util.Collection 2. java.util.Set 3. java.util.SortedSet 4. java.util.List 5. java.util.Map 6. java.util.SortedMap 7. org.apache.commons.collections.Bag 8. org.apache.commons.collec

RE: Are FastArrayList/FastHashMap broken (unthreadsafe)

> So are you saying your patch won't work? > http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=101953795432669&w=2 > > :) > > > That patch is still on my radar. I just haven't had the chance to do > anything with it yet. I've been swamped with too many other things. *blush* I thought th

RE: [collections] - Few more collections for the masses... (important for Struts view objects, maybe other projects)

> Obviously, list and map implementations respectively... > http://www.keyboardmonkey.com/next/ReserveList.java > http://www.keyboardmonkey.com/next/ReserveMap.java Haven't looked in-depth at the code, but a few thoughts already: 1. I'd like to see implementations for all eight collection inte

RE: Are FastArrayList/FastHashMap broken (unthreadsafe)

> > I have just been looking through the source code to the classes > > org.apache.commons.collections.FastHashMap and > > org.apache.commons.collections.FastArrayList - these classes seem totally > > broken to me because they are designed for use within a multi-threaded > > environment but ar

RE: [collections] Would like to contribute my RangeIterator

And to use a RangeIterator over a collection that isn't sorted, you'd probably create a sorted collection first: new TreeSet(collection, comparator).subSet(first, last).iterator(); seems like it does what RangeIterator does. -Paul -Original Message- From: James Strachan [mailto:[EMA

RE: [Collections][SUBMIT] TypedList

Hi Michal, In another thread ([SUBMIT] WeakHashSet) we've been discussing having a two-transformer based approach that would let you handle strings in the way you describe. The functionality we were trying to achieve was the ability for a list or set or map to transform objects into WeakReferenc

RE: [Collections][SUBMIT] WeakHashSet

> I'm not sure a two transformer approach is all thats needed. Collections > have three basic types of method: > - input (add/set) > - query (indexOf, contains, equals, remove) > - output (get, toArray) > The Predicate/Transform proposal covers only the input group at the moment. > > A 'two transf

RE: [Collections][SUBMIT] WeakHashSet

> > // Creates a Set backed by the given map. Given > > // map must be empty. > > public static Set createSet(Map map); > > > > public static SortedSet createSortedSet(SortedMap map); > > This kind of depends on how a Set is backed by a Map. (You'll have to > forgive me for not knowing h

RE: [Collections][SUBMIT] WeakHashSet

Hi, I have a few thoughts regarding your WeakHashSet... My first thought was to somehow integrate it with the whole Transformer/Predicate collections we've been discussing in another thread. So you'd have a Transformer that converted an object into a WeakReference before storing it in the set

RE: [Collections][SUBMIT] TypedList

> PredicatedList would just take a Predicate in its constructor, and > anytime someone adds an element it throws an exception if the > predicate's evalute method returns false on the element. Then when > TypedList extends PredicatedList it becomes a very small class that > simply constructs a Typ

RE: [Collections][SUBMIT] TypedList

> The way I did this was: > > TypedStructure interface. AbstractTypedStructure class. > IllegalTypeException exception. > > Then TypedSet/List/Map implement Set/List/Map and extend > AbstractTypedStructure. Hehehehe...we *could* use dynamic proxy classes to provide one factory method that woul

RE: [Collections][SUBMIT] TypedList

Hi Steve, Your TypedList got me thinking...At first I thought, wouldn't it be nice to specify a parameter that would allow the null element (sometimes I need a list that allows nulls)...then I got to thinking, actually wouldn't it be nice if the validate() method could be overridden by a subcla

[PATCH][Collections] Thread-safe fast collection classes

Attached are modifications to FastArrayList, FastHashMap, and FastTreeMap... 1. Sublists, submaps, map collection views, iterators and list iterators are all thread-safe now. Many many package-protected classes were added to achieve this. 2. Serialization has been somewhat improved. 3. toS

RE: [SUBMIT] OptimizedFastArrayList

> Is there any external behavior difference between FastArrayList and your > OptimizedFastArrayList (other than performance)? If so, can you > explicitly specify the differences and why? If not, is there a reason not > to just replace the existing FastArrayList with the faster implementation?

[SUBMIT] OptimizedFastArrayList

Furthering my obsession with FastArrayList... Attached is a new List implementation inspired by but faster than FastArrayList. From the javadoc: Optimized thread-safe array-backed dynamic java.util.List implementation. The list is backed by a dynamic array; the array will grow automatically a

Further thoughts on FastArrayList, FastHashMap, FastTreeMap

Can we generalize? It seems that FastHashMap could just as easily accept any Map implementation in its constructor. In other words, it could work just as well with java.util.IdentityHashMap or java.util.WeakHashMap or org.apache.commons.collections.DoubleOrderedMap: public class FastMap imple

FastArrayList, FastHashMap, FastTreeMap not thread safe

Hi, I noticed that version 2.0 of the Commons Collections has been released so I thought I'd browse through the code. While doing so I noticed something about FastArrayList, FastHashMap and FastTreeMap. List and Map objects can return views on their contents that can be modified. For instance