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
