commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject Re: [collections] suggestion for improvement: QueryableCollections
Date Mon, 16 Jan 2012 14:56:05 GMT
Am 16.01.2012 12:00, schrieb Benedikt Ritter:
> Am 15.01.2012 20:23, schrieb James Ring:
>> Google Guava has all this and more, and it doesn't require an
>> extension to
>> ArrayList, any Iterable will do.
> Hi James,
> thanks for the response! I agree with you, that google guava does the
> same and that it does it better. In fact I do think, that there are
> things, that guava does even better than commons collections. For
> example using generics...

Hi James its me again,

browsing through github, I found a mirrored commons collections 
repository. And guess what: they have already implemented generics for 
the next release to come. To be honest, I should have looked at the 
trunk of collections svn repository. I'm sorry, that I didn't and send a 
almost completely pointless post to the mailing list.

However, I have decided to fork commons collections mirrored github 
repository and try to see, if I can improve something. So stay tuned!


> However, what I do not agree with, is that this means, that there is no
> need for an extension of commons collections. I mean, then ASF could
> also stop developing tomcat, because there are clearly other application
> servers out there, that provide all functionality that tomcat has and
> maybe more.
> The FAQs on how to contribute just say "if you see something that can be
> improved, create a patch". And not "...that can be improved, but has not
> yet been implemented in some other library".
> If "not implementing functionality, that has been implemented elsewhere"
> is a common policy of commons or of commons collections, then I would
> recommend to put this in the FAQs on how to contribute (although I
> think, that would be a very bad thing to do, as I pointed out above).
> Having all that said, I still think that linking Predicates to queries
> would be a real improvement for commons collections. And I still would
> like to contribute the functionality somehow. I see your point, that
> extending java base classes is not the best thing to do. But as I said:
> I am willing to make what ever adjustment is required (also it seems to
> me, that this means re-writing the hole thing from scratch ;-)
> So, what do you think?
> Regards
> Benedikt
>> On Jan 15, 2012 3:59 AM, "Benedikt Ritter"<>
>> wrote:
>>> Hi,
>>> I have written a small extension for java.util.ArrayList, that allows
>>> for
>>> qerrying Lists using (generic) predicates. In addition to that, I
>>> adapted
>>>**domain.Specifications class as a util to
>>> link predicates to queries. Here is how it works:
>>> QueryableList<Customer> qList = new QueryableArrayList<Customer>()**;
>>> qList.addAll(getCustomers());
>>> qList.getAll(new Predicate<Customer>() {
>>> public boolean evaluate(Customer element) {
>>> if (element.getLastName().**startsWith("B")) {
>>> return true;
>>> } else {
>>> return false;
>>> }
>>> }
>>> });
>>> This will give you a List containing all customers, that match the given
>>> predicate. Using the Query class, we can link predicates via AND and
>>> OR or
>>> simply neglect them (the next example assumes, that we have a static
>>> import
>>> of the not and where method and startsWith(String) and bornAfter(int)
>>> are
>>> util methods, that return predicates):
>>> List<Customer> queryResult = qList.getAll(not(startsWith("**B")));
>>> queryResult =
>>> qList.getAll(where(startsWith(**"B")).or(startsWith("C")));
>>> queryResult =
>>> qList.getAll(where(startsWith(**"B")).and(bornAfter(1980)));
>>> In addition to that, there are implementations of common collection
>>> methods using predicates:
>>> public boolean containsMatch(Predicate<E> predicate);
>>> public Iterator<E> matchIterator(Predicate<E> predicate);
>>> public boolean retainAllMatches(Predicate<E> predicate);
>>> public boolean removeAllMatches(Predicate<E> predicate);
>>> ...and common list methods:
>>> public int indexOfMatch(Predicate<E> predicate);
>>> public int lastIndexOfMatch(Predicate<E> predicate);
>>> I think QueryableCollections would fit nicely into commons collections,
>>> because as far as I know, commons collections only offers you the
>>> opportunity to validate if all elements in a collection match a given
>>> predicate. There is no possibility to easily query for objects matching
>>> some criteria.
>>> Having that said, I would like to contribute all source code of
>>> QueryableCollections. I am willing to make what ever changes are
>>> required.
>>> Here are some thinks that I think will need to be adjusted before
>>> contribution:
>>> - swtich from my generic Predicate implementation to
>>> org.apache.commons.**collections.Predicate,
>>> although I really would like to see generics in commons collections. It
>>> saves you all the instanceof statements.
>>> - As far as I can see commons collections does not extend classes from
>>> java.util.* but decorates them. As I said QueryableArrayList is an
>>> extension of ArrayList. If there is a general policy of not extending
>>> java
>>> base classes, this would have to be changed.
>>> - Re-Implement jUnit tests using jUnit 3.8.1 (instead of jUnit 4.1.0)
>>> - change licence agreement von LGPL to Apache License
>>> All source code (and example code) is available at github:
>>> HEAD:
>>> v0.1.0:**QueryableCollections/tree/**
>>> stable-0.1.0<>
>>> You can download a build from my blog:
>>> http://www.systemoutprintln.**de/wp-content/uploads/**
>>> collections-0.1.0.jar<>
>>> I'm really exited to hear what you guys think of QueryableCollections.
>>> Regards
>>> Benedikt Ritter
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.**<>
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message