Open Source Support Tools
 
Search Item
 
Summary
  Reported Issue
Title: [COLLECTIONS-213] CollectionUtils API extension: algorithm methods accept an Iterator argument
Project: collections
Item Last Modified: Mon, 3 Nov 2008 19:43:08 -0800 (PST)
Tags:  
 
 
Bug add added addition apache apache-project api apply applying argument arraylist attach attaching backed cardinality cases change collection collections collectionutils contribute element elements functionality implement iterator iterators iteratorutils javadoc jdk jira junit list made method methods npe null objects patch predicate return returns something src stephen test tests throw thrown transform transformed transformer unresolved
Details
[COLLECTIONS-213] CollectionUtils API extension: algorithm methods accept an Iterator argument
Reporter:   Dusan Chromy
Created:   Wed, 31 May 2006 21:07:37 -0700 (PDT)
Updated:   Mon, 3 Nov 2008 19:43:08 -0800 (PST)
Key:   COLLECTIONS-213
Versions:   Not provided
Environment:  
Priority:   3
Status:   Open
Resolution:   Unresolved
Original Link:   http://issues.apache.org/jira/browse/COLLECTIONS-213
Summary:   CollectionUtils API extension: algorithm methods accept an Iterator argument
Description:
I just finished the Iterator additions to CollectionUtils, including test cases and I am going to
attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works <img class="emoticon" src="https://issues.apache.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/>

<p>At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the
new signature, until I noticed the collect method already accepts an Iterator argument.</p>

<p>Following methods now accept an Iterator argument (besides collect):</p>

<p>cardinality
find
forAllDo
countMatches
exists</p>

<p>I also noticed cardinality used to throw a NPE if the collection argument was null.
I see no reason why it should not return zero. The Iterator flavour does return zero
and I also modified the Collection version to return zero (including Javadoc
modification) for the sake of consistence.</p>


<p>I stopped to think for a while before touching the method, but the fact
that the Javadoc does not mention "may not be null" made me think the NPE is not thrown
intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..),
which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection)
method if you think otherwise.</p>

<p>I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified
the latest version. Anyway, please double-check before commiting the changes.</p>

<p>Cheers,</p>

<p>Dusan</p>


<p>> I think that these methods would make useful additions to the API.
>
> I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great.
>
> Stephen
>
>
> dusan.chromy@freenet.de wrote:
>
> > I've been using some algorithm methods from the CollectionUtils, for example
> > find(Collection, Predicate)
> > exists(Collection, Predicate)
> > countMatches(Collection, Predicate)
> > forAllDo(Collection, Closure)
> >
> > However, I would also like to be able to use these algorithms with an Iterator:
> >
> > find(Iterator, Predicate)
> > exists(Iterator, Predicate)
> > countMatches(Iterator, Predicate)
> > forAllDo(Iterator, Closure)
> >
> > The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work.
> >
> > What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0).
> >
> > If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned.
> >
> > Best Regards,
> >
> > Dusan Chromy
>
> </p>
Comments:
bobik72 Wed, 31 May 2006 21:09:34 -0700 (PDT)
Addition of algorithm methods with an Iterator argument
bobik72 Wed, 31 May 2006 21:10:38 -0700 (PDT)
JUnit tests for newly added methods
bobik72 Fri, 16 Jun 2006 15:49:38 -0700 (PDT)
It just occured to me - in the middle of CollectionUtils-style programming - that the addition of the Iterator flavours methods will not only improve performance by avoiding the unnecessary conversion from iterator to List, but also add the following benefit:

Imagine you have an input collection of "raw" objects which you transform to something else by applying a Transformer. Now if you're only interested in finding a transformed object that satisfies a given predicate, having an Iterator flavour of find/exists method will allow you write a code like this:



Predicate predicate = ... ;
Transformer transformer = ... ;
CollectionUtils.find( IteratorUtils.transformedIterator( rawList.iterator(), transformer ), predicate );



This is going to perform better than the workaround:



CollectionUtils.find( CollectionUtils.collect( rawList, transformer ), predicate );



Because the latter needs to apply the transformer to all elements in the list, even if the first transformed element satisfies the predicate.

shammah Mon, 4 Feb 2008 14:13:00 -0800 (PST)
BTW, CollectionUtils has been updated in the 4.0 branch to take Iterable as a parameter wherever possible.

But that CollectionUtils.find( CollectionUtils.collect( rawList, transformer ), predicate ); optimisation presents an interesting challenge to doing something similar with Iterables.

mbenson Tue, 18 Mar 2008 21:59:16 -0700 (PDT)
Considering that IteratorUtils.toList(Iterator) is available, I don't see much value here and would vote WONTFIX. Dissent?
rovrevik Mon, 31 Mar 2008 12:40:25 -0700 (PDT)
Sorry for the delay in responding to the suggestion to close this
feature request.

Unless I am missing something, the functionality provided by creating
an intermediate list is not sufficient for our use cases. We use
iterators in a pipes and filters-based batch process. The iterators
are backed by fifo queues that are populated from database records.
Using the intermediate list approach would require that all items
piped through the process would first be read into (and stay in)
memory.

bayard Tue, 20 May 2008 00:29:16 -0700 (PDT)
Attaching Dusan's changes as a patch as it's hard to work with old copies.