Hi Daniel!
Yes, you are right. As written in my mail to Gary: I think it would be enough
for now if we'd come to the same results as before the module privacy
restrictions. If we do better later on it is an optional bonus.
LieGrue,
strub
> Am 07.03.2024 um 15:39 schrieb Daniel Watson <dcwatso...@gmail.com>:
>
> One comment about the collection comparison...
>
> For any collection that actually implements List, equality should *include*
> order, not attempt to ignore it, right? The contract of a list is that the
> order is consistent, and two lists with the same items in different order,
> should not be considered equal.
>
> e.g for List:
>
> Best case scenario - The lengths are different and you dont have to check
> any equalities
> Worst case scenario - every item is equal and you have to iterate both
> lists completely
> Remaining Cases - Item [i] is different and you dont have to check
> anything past that
>
> (For pretty much any collection I think the best case is the same)
>
> For sets, maybe it could be optimized by creating a new collection and
> removing items as you find them, so each step necessarily gets smaller? Not
> sure about this though.
>
>
>
> On Thu, Mar 7, 2024 at 8:55 AM Gary D. Gregory <ggreg...@apache.org> wrote:
>
>> 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
>>> 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
