11

After upgrading commons-collection from 3.2.2 to 4.1, I am having issues with comparing collections for BeanPredicate and EqualsPredicate. BeanPredicate is from commons-beanutils jar and EqualsPredicate is from commons-collection.jar.

BeanPredicate namePredicate = new BeanPredicate(propertyName, new EqualPredicate("someString"));

As per Latest commons-collection jar 4.1 ,EqualsPredicate Constructor accepts parameterized type like 

public EqualPredicate(T object)
{
 this(object, null);
}

not the object which was there in 3.2.2

public EqualPredicate(Object object)
{
this.iValue = object;
}

BeanPredicate has no parameterized type like <T> for its constructor thats why I am getting compilation problem and not able to build relation ship between these two predicates.I saw latest commons-beanUtils 1.9.3 BeanPredicate jar also there also BeanPredicate constructor is not parameterized. I tried giving type also but its not working.How to fix this issue any help would be appreciated.

Pradeep
  • 1,947
  • 3
  • 22
  • 45
  • 1
    This incompatibility is not really fixable. But you can easily (copy/paste) have your compatible `BeanPredicate` (you have to replace `org.apache.commons.collections.Predicate` by `org.apache.commons.collections4.Predicate`, add a `` on the class and a cast in `predicate.evaluate((T) propValue);`). Then you can `BeanPredicate namePredicate = new BeanPredicate<>("propertyName", new EqualPredicate<>("someString"));` –  Nov 20 '17 at 06:47
  • hi Predicate interface I cannot manipulate since I am not using Predicate directly in my class .Moreover it is implemented by either EqualPredicate and BeanPedicate – Pradeep Nov 20 '17 at 07:39
  • 1
    I don't understand, sorry. What I mean is create a new `BeanPredicate` of your own. If that's not a possibility you'll have to edit your question and explain why. –  Nov 20 '17 at 07:58
  • If creating a custom BeanPredicate class which adheres to my requirement is only the option then I need to check since addition of new class requires some level of approvals. Thnx for your inputs. – Pradeep Nov 20 '17 at 08:30
  • Even if we think generally also this a flaw as per the api standards r8 since upgrading one jar with few changes which other jar won't support is a mess .Agree – Pradeep Nov 20 '17 at 08:32
  • This is working as expected. Bean utils jar has dependency on collections jar 3. There are more changes to be done to make the bean utils to work with collections jar 4.. Wait for the [jira](https://issues.apache.org/jira/browse/BEANUTILS-500) to resolve which will have a new bean utils version with dependency on collection jar 4. Notice the new `EqualsPredicate` in collections version 4 is a completely different package (`org.apache.commons.collections4.functors`) . Keep both the commons collections jars 3 and 4 if you want to use newer version. – s7vr Nov 21 '17 at 07:01
  • Thanks Veeram.Yes if we keep both the jars it will work fine but what is the point in making upgrade if we keep the old jar. Moreover import statements will point to collections 4 only.Sure I will wait for the Jira to close . – Pradeep Nov 21 '17 at 07:07
  • As of now I went by creating new BeanPredicate custom class with my required code and added the new class references everywhere.It is working fine.Even RC also suggested the same – Pradeep Nov 21 '17 at 07:13
  • my maven dependency tree shows: commons-beanutils (in the latest version: 1.9.3), depends on commons-collections 3.2.2. And there were (one of them you pointed out in your question) some "major refactorings" between 3 and 4 ... so you can't/shouldn't (fully) upgrade to commons-collections 4.x, as long as you need the beanutils... – xerx593 Jan 14 '19 at 17:33
  • Pradeep, Please feel free to post your resolution as a new answer and accept the answer. @xerx593 you certainly can upgrade code to collections4 and still keep commons-collections 3.x around via transitive library dependencies. Personally, I recommend it because 4.x is just so much better. – AndrewF Feb 16 '22 at 06:48

0 Answers0