I agree, field-to-field is a recipient for headaches. I think the
comparison should be done using the public API. An interesting tangent is
what Commons Lang's EqualsBuilder reflectionEquals API shows, likely
similar issues which is understandable.

Gary

On Fri, Sep 13, 2024, 11:11 AM Willi Schönborn <w.schoenb...@gmail.com>
wrote:

> I'm assuming that's a private field in which case it shouldn't be
> documented because it shouldn't be relied on in any way.
>
> My 2c
>
> On Fri, Sep 13, 2024, 16:09 Kaan Berk Yaman <kaan.ya...@student.kit.edu>
> wrote:
>
> > Hello,
> >
> > I was doing some testing with a record that has an
> > ArrayListValuedHashMap as one of its components. I use AssertJ to do a
> > deep, recursive, field-to-field comparison of the record. All of the
> > members of the list-valued map have respective `equals` and `hashCode`
> > implementations. I have, however, noticed that, when I have two equal
> > LV-maps, if I call `asMap` on one, AssertJ reports that the two
> > LV-valued maps are not equal, due to the `asMapView` field, which is
> > `null` for the other LV-map; this field seems to be initialized upon the
> > first call of `asMap`. The assertion runs through if I call `asMap` on
> > the other map, too.
> > It seems like `asMapView` is kept updated as long as `asMap` is called
> > at least once. Is this expected behaviour? If yes, I feel like this
> > should be documented somewhere; the Javadoc comment of `asMap` has no
> > mention of `asMapView` and how this field is used for caching.
> >
> > Thanks in advance.
> >
> > Kind regards
> > Kaan
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
>

Reply via email to