Hi Gregory!

I did try this out and figured that I didn't think it though. Maybe I need to 
go a few steps back and explain the problem:

I have the following constellation

public class SomeInnerDTO {int field..} // NOT implements equals!
public class TheOuterDTO{ List<SomeInnerDTO> innerList;..}

My problem is that reflectionEquals (which I use in a unit test) tries to 
introspect fields even in java.util.classes. And for getting the values of 
those classes it tries to call a setAccessible(true); 
And obviously here it fails. There is a ticket already open [1] which sugggests 
to use trySetAccessible. But I fear that will still do nothing and you won't 
get access to those inner knowledge inside java.util.LinkedList etc.

And using equals() on the List sadly won't help either, as the SomeInnerDTO 
would also get compared with equals(), but that will obviously use identity 
comparison only :(


What I did for now (running all tests with a few projects right now, but looks 
promising):

diff --git a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java 
b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
index ff5276b04..cf878da40 100644
--- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
+++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
@@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object lhs, 
final Object rhs) {
             if (bypassReflectionClasses != null
                     && (bypassReflectionClasses.contains(lhsClass) || 
bypassReflectionClasses.contains(rhsClass))) {
                 isEquals = lhs.equals(rhs);
+            } else if (testClass.isAssignableFrom(List.class)) {
+                List lList = (List) lhs;
+                List rList = (List) rhs;
+                if (lList.size() != rList.size()) {
+                    isEquals = false;
+                    return this;
+                }
+                for (int i = 0; i < lList.size(); i++) {
+                    reflectionAppend(lList.get(i), rList.get(i));
+                }
             } else {

I'm rather sure this is still not enough and there are plenty other cases to 
consider. Like e.g. handling Maps etc.
But at least that's the direction I try to approach it right now. And of course 
this new part should potentially also be enabled by a flag...

Will keep you updated.

txs and LieGrue,
strub


[1] https://issues.apache.org/jira/browse/LANG-1711

> Am 06.03.2024 um 13:18 schrieb Gary Gregory <garydgreg...@gmail.com>:
> 
> This sounds like a good idea to try. I would call the option something else
> though. We would not skip calling equals if it is defined right? How about
> "useEqualsIfPresent".
> 
> Gary
> 
> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
> 
>> Hi!
>> 
>> I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards
>> we get more and more nasty module problems. Mainly because the code tries
>> to recurse into java.util.* classes as well.
>> I know that I can use setBypassReflectionClasses for those. But wouldn't
>> it be fine to have an additional switch to 'skipOnCustomEquals' or similar?
>> 
>> The idea is to only use reflection on classes which do not provide their
>> own equals method. One can test this imo rather easily by checking whether
>> classInQuestion.getMethod("equals", Object.class).getDeclaringClass() !=
>> Object.class
>> Do that for lhs and rhs and if both fit the criteria -> invoke equals
>> 
>> Wdyt of that idea? Worth trying or is there already a better solution?
>> With the new flag we can make sure that we do not change the current
>> behaviour for existing use cases.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to