Hi Gary!
Yes, this would be really slow. Plus after further thinking about it, I guess
it doesn't add anything over the required existing behaviour imo. Until now
reflectionEquals did simply dig into the Class.getDeclaredFields of those
java.util.* classes. So it only did compare the EXAKT same situations. having
differences in internal hash codes or whatever would result in detecting a
difference. So probably just iterating over the entries is perfectly fine for
now.
Same for Maps. Not sure though, whether we should just iterate over the entries
and compare those, or do a map lookup (which would require equals again).
Btw, I thought again about the 'customEquals' part. Maybe we cannot rely on it
fully, means if it returns false it doesn't mean they are really different.
Otoh IF it returns true, then we can take it for granted, that those two are
the same. And further thinking about it: what if we *always* invoke equals()
first, and if it returns true -> return true and skip the rest for this tree?
LieGrue,
strub
> Am 07.03.2024 um 14:55 schrieb Gary D. Gregory <ggreg...@apache.org>:
>
> On 2024/03/07 06:58:30 Mark Struberg wrote:
>> The question to me is how we can make it more robust.
>> In a Collection (but actually also in most lists) the order in which you get
>> the values (Iterator or get(i)) is not deterministic. It can be different in
>> one list than in another - even if they contain the exact same items.
>
> Hm, so to iterate through Lists in parallel would work but not with Sets.
>
>>
>> Not yet sure how to work around this. We can probably try to sort it first,
>> but then again, if they do not implement Comparable it won't help much. Or
>> do a containsElement based on reflection as well - but that would be rather
>> slow.
>
> This is one of those: If you want support for the feature, it'll work, but
> it'll be slow because there is no other way to do it (for now if ever).
>
> Gary
>
>>
>> Same with Maps. There is a good reason why the key at least should implement
>> equals/hashCode. If this is not the case, then we are not able to implement
>> this properly I fear.
>>
>> Any ideas?
>>
>> LieGrue,
>> strub
>>
>>> Am 06.03.2024 um 15:53 schrieb Gary Gregory <garydgreg...@gmail.com>:
>>>
>>> Ah, right, custom "non-equalable" _inside_ Collections and Maps...
>>>
>>> For the diff, I'd suggest you test and iterable over a Collection
>>> instead of a List.
>>>
>>> Then you'd need a separate test and traversal for Map instances.
>>>
>>> (Still no common super-interface in Java 21 for Collections and Maps...)
>>>
>>> Gary
>>>
>>> On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg <strub...@yahoo.de.invalid>
>>> wrote:
>>>>
>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> <mailto:dev-unsubscr...@commons.apache.org>
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> <mailto:dev-h...@commons.apache.org>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org
> <mailto:dev-h...@commons.apache.org>
